Engine preprint: original page layouts
The complete supplied preprint is available here as vector page layouts, including the original contents, equations, tables, code, figures, references and appendices. The ordered web book provides searchable text, sections and current-guide links. These page layouts preserve source fidelity when extraction cannot express mathematical typography. Neither edition establishes that proposed interfaces are implemented.
Page 1
Extracted text for page 1
Reaktor: An Extensible Engine for
Applications and Distributed Systems
Typed Port Hypergraphs, Blueprint Authoring,
Polyglot Execution, and Controlled Evolution
Reaktor Project
BestBuds Ventures
16 September 2026
Technical preprint
Abstract
Application development repeatedly reconstructs the relationships among user interfaces, state,
services, data, deployment, and operational tools. Reaktor is an architecture for an extensible
application-and-distributed-systems engine in which reusable mechanisms carry the contracts required
to compose, execute, inspect, and evolve them. Engineers implement mechanisms; product developers
compose applications through readable source or a Blueprint-style language; software agents use the
same contextual queries and guarded operations. The common representation is a typed, attributed,
hierarchical port hypergraph. Nodes own ports, binary edges and hyperedges express connectivity, and
protocol profiles define interaction behavior. Shared service interfaces elaborate into language-neutral
contracts, while deployment refinement maps logical boundaries to concrete mobile, browser, edge,
JVM, and native realizations. The reference stack connects Kotlin Multiplatform, Compose, React,
Hermes, FFI, stores, cloud resources, build tools, and observability without treating them as one
universal runtime. A photograph-message walkthrough links authoring to execution, diagnosis, and
change. Data-oriented snapshots and compiled bindings separate architectural analysis from the
invocation hot path. LiveUpdate supports qualified subgraph replacement through compatible artifacts,
generation-pinned execution, state ownership, and recoverable activation. Mathematical foundations
cover graph structure, composition, computation, distributed algorithms, sparse algebra, hardware
constraints, and formal assurance. Constructed adoption studies range from solo offline applications
to enterprise estates and robot fleets. Conditional propositions and a reproduced finite lifetime model
establish narrowly scoped results; they do not constitute an end-to-end implementation proof. The
central empirical question is whether integrated contracts and reusable mechanisms reduce duplicated
engineering work and boundary failures enough to justify the engine’s cost.
Keywords: application engines; Blueprints; port hypergraphs; distributed systems; formal methods;
polyglot execution; live updates; software agents.
Page 2
Extracted text for page 2
Reaktor: An Extensible Software Engine Technical preprint
Before the introduction: building applications inside an engine
A game engine does not merely draw a diagram of a game. It supplies mechanisms—rendering, input,
animation, resources, networking—and an environment in which those mechanisms can be composed
into an experience. A developer can work on a reusable movement system while a designer builds an
encounter using it. Both operate within a shared vocabulary whose objects can be authored, executed,
inspected, and packaged. Unreal Engine’s Blueprints make this relationship concrete: programmers
expose functionality that other authors extend and combine through typed visual programs [1, 2].
Reaktor applies that engine model to applications and distributed systems. Its reusable mechanisms
concern identity, services, state, navigation, media, data, background work, communication, rendering,
deployment, and operational tools. Product developers compose those mechanisms into experiences.
Framework engineers extend the mechanisms when a product exceeds their expressive boundary. Software
agents can participate in either activity through the same contracts, source representations, and controlled
operations. The intended result is not less programming in every circumstance; it is less repeated
implementation of the same cross-platform and cross-system mechanisms [3, 4].
One feature, rather than seven disconnected integrations
Consider a photograph attached to a conversation. The user selects or captures an image, edits a caption,
and presses send. The application preserves a local draft, transfers the media, authorizes the publication,
records the accepted message, performs any permitted processing, updates recipients, and displays
progress. Background scheduling, offline recovery, notifications, and instrumentation all participate. A
later change may affect only the preview interface, or it may require a new native imaging capability.
In Reaktor’s target authoring model, this feature is a composition of reusable components with explicit
boundaries. The developer selects implementations appropriate to mobile, browser, edge, or server
execution. The framework connects the composition to the resources and tools that realize it. A visual
editor and readable source describe the same supported program; a running instance reports observations
against the same logical identities. The feature can be investigated from its screen, service, data projection,
deployment, or test without inventing a separate description for each tool.
The intended chain is therefore active, not merely documentary:
compose a feature → bind its implementations → build and run it
→ deploy its resources and artifacts → inspect its behavior
→ validate and release a compatible change.
A framework cannot infer the intended product policy from connectivity alone. The developer still decides
who may publish, what constitutes acceptance, which failures need user recovery, and whether an image
is allowed to leave the device. Reaktor’s contribution is to make those decisions reusable, connected, and
enforceable where suitable mechanisms exist.
The graph is the engine’s shared representation
A node is a component or structural entity. A node owns ports describing its interface. An edge connects
ports; a hyperedge connects a role-labelled group of participants, such as a publication and several
independent subscriptions. A protocol says what may happen across a connection. Modules expose
selected owned ports as their boundaries. Implementations and deployment plans explain how those
logical components execute.
Other relationships connect this executable structure to schemas, policies, source symbols, cloud
resources, tests, and observations. These relationships are not all executable wires. The system is one
coherent model with multiple authoritative sources and views, not one giant process or graph database.
Ordinary requests execute specialized bindings, not architectural graph queries.
2
Page 3
Extracted text for page 3
Reaktor: An Extensible Software Engine Technical preprint
Activity Without an integrated engine Reaktor target
Add an upload feature Assemble UI, native adapters, service Compose a versioned feature whose
clients, storage, retries, and diagnostics supplied implementations and
obligations remain attached
Change a shared Find each client, route, serializer, test, Elaborate one shared contract into the
operation and dashboard mapping supported bindings and associated
metadata
Investigate a failure Reconstruct relationships across source, Follow a feature identity through the
logs, and resource consoles participating runtime and evidence views
Delegate Explain architecture repeatedly and Supply a bounded working set, typed
implementation review loosely related edits operations, and explicit acceptance
obligations
Ship dynamic behavior Rely on a loader-specific bundle Activate a supported subgraph
convention replacement against host, state, and
lifecycle contracts
Table 1: The proposed change in engineering work. A competent conventional stack already automates parts of
each row; the evaluation must measure the additional value and cost of connecting them.
Where the change is substantive
The reusable unit is larger than a code library and more durable than a copied application template. A
feature can carry a typed interface, alternative runtime implementations, resource requirements, authoring
metadata, test fixtures, operational actions, and scoped assurance evidence. Not every package supplies
every item. Its manifest makes the available support and remaining work explicit.
This is also how the engine grows. A native–Hermes bridge initially requires systems work: loading
code, moving values, managing lifetimes, preserving state, and recovering from failed activation. Once
those mechanisms have usable contracts and tooling, several applications can compose supported dynamic
behavior without rebuilding the bridge. New mechanisms expand the set of realizable systems; composition
turns that engineering investment into repeated product leverage.
The reference stack is Kotlin Multiplatform, Compose and React surfaces, native C++/Hermes
integration, Cloudflare edge resources, JVM services, and selected data and build systems. Existing
libraries, cloud platforms, and development tools remain responsible for their specialized jobs. Reaktor
connects them and supplies reusable runtime mechanisms; it does not claim to replace every editor,
database, or orchestrator [3, 5, 6].
Design scope and evidence
The complete engine, Blueprint, deployment, and verification loop specified here is a target architecture.
The underlying repositories contain working graph, service, actor, platform, and tooling slices, alongside
partial integrations and unimplemented designs. Implementation observations refer to the pinned source
inventory in Appendix F; examples marked as proposed interfaces are specifications, not released APIs.
Mathematical propositions state their assumptions. The executable reference model checks a finite lifetime
protocol, not the complete Reaktor implementation. This separation permits a concrete engineering
proposal without confusing its destination with its current implementation.
3
Page 4
Extracted text for page 4
Contents
Before the introduction: building applications inside an engine 2
1 Motivation, contributions, and scope 5
2 The engine model: mechanisms, Blueprints, and product composition 6
3 A feature from composition to production change 8
4 The concrete Reaktor reference stack 12
5 Blueprint authoring and reusable feature packages 14
6 The workbench: edit, run, inspect, and explain 17
7 A shared model across authoring, execution, and observation 18
8 Mathematical foundations for architectural reasoning 20
9 The graph-theoretic model 22
10 Network views, sparse algebra, and architectural analysis 25
11 Ports, contracts, and shared service interfaces 27
12 Interface contracts and implementation architecture 30
13 Hyperedges, modules, and graph rewriting 35
14 Computational semantics and flow-based programming 36
15 Distributed algorithms behind the execution model 39
16 Platform integration, lifecycle, and adaptive capabilities 42
17 Behavior and distributed execution 43
18 The system knowledge graph and data layer 45
19 Federation, data contracts, and operational integration 48
20 Identity, tenant isolation, secrets, and encrypted communication 51
21 Application protocols: work, mesh, notifications, and entry 53
22 Polyglot execution, Switchboard, and the UI engine 54
23 Build, cloud, observation, and reproducible development 57
24 Compilation and data-oriented implementation 59
25 Hardware, resource budgets, and performance semantics 61
26 LiveUpdate: replacement of supported subgraphs 63
27 A concrete LiveUpdate coordinator 68
28 Human and agent authoring 70
29 Capability growth and the changing division of programming work 71
30 Assurance and formal guarantees 75
31 Constructing an assurance argument 77
32 Heterogeneous and cyber-physical systems 80
33 Application and adoption studies 83
34 Industrial precedents and their limits 91
35 Evaluation agenda and limitations 95
36 Implementation sequence and acceptance milestones 96
37 Conclusion 97
References 98
A Notation and representation interfaces 105
B Update failure obligations 106
C Terminology and reading conventions 107
D Reproducibility of the finite reference model 108
E Study guide and implementation exercises 109
F Source lineage, maturity, and explicit design decisions 112
4
Page 5
Extracted text for page 5
Reaktor: An Extensible Software Engine Technical preprint
1 Motivation, contributions, and scope
Application engineering repeatedly crosses boundaries that individual tools describe differently. A screen
depends on a route and state owner; a service depends on a schema, credential, data store, and deployment;
a release changes several of these together. Shared types, generated clients, infrastructure-as-code, build
graphs, and observability already reduce parts of this work. The unresolved integration problem is keeping
their relationships meaningful through authoring, execution, and change.
Reaktor treats application composition as an engine responsibility. Its structural foundation is a typed,
attributed, hierarchical port hypergraph. Its protocols define communication behavior. Its module and
realization interfaces connect that model to ordinary language implementations, devices, services, data,
and tools. Its workbench exposes source and visual authoring, runtime inspection, and reviewed operations
over the same supported semantics [3, 7, 8].
Three constraints follow from the existing implementation. Ports remain owned by nodes. Shared
service interfaces remain the principal client/server authoring agreement. Richer metadata must not
introduce architectural traversal into every local call. BestBuds’ common messaging API, actor-based
orchestration, and nested application graph are concrete sources of these constraints [9, 10].
1.1 Contributions
The specification contributes a coherent design across five boundaries: component interfaces and collective
connections; textual and visual composition; logical structure and physical realization; system knowledge
and operational evidence; and supported dynamic replacement with state and lifetime obligations. It
develops the mathematical vocabulary needed to reason about those boundaries and specifies how
extensions add functionality without turning the kernel into a separate implementation of every subsystem.
The architectural hypothesis is that this integration can reduce independently maintained descriptions,
improve change localization, and make reusable mechanisms accessible to humans and agents. Those
are evaluation questions, not consequences established solely by the graph model. The formal claims
are narrower: representation preservation, closure, composition under explicit contracts, validated patch
publication, and selected generation-lifetime properties.
1.2 Requirements and exclusions
The common case must remain small: an in-process feature, an ordinary service call, or a local state
store should not require a distributed registry or an agent. Collective messaging, sessions, streams,
state subscriptions, platform resources, and remote implementations need explicit semantics when used.
Foreign systems enter at a declared level of knowledge and authority. A source scanner can contribute
navigation without granting deployment power.
The architecture does not provide automatic verification of arbitrary programs, arbitrary source
round-tripping, transparent relocation of unrestricted object references, or safe replacement of arbitrary
native code. It does not make every application a distributed actor system. Real-time controllers and
cryptographic engines retain their own qualified implementation boundaries. Product usefulness, usability,
and business correctness still require human validation.
1.3 Reading routes
Sections 2–6 establish the authoring model, a complete feature walkthrough, the concrete reference stack,
and the development experience. Sections 8–15 supply the structural and computational foundations. The
realization chapters explain the runtime, data, identity, UI, cloud, and update mechanisms. The later
chapters address human–agent work, assurance, heterogeneous systems, adoption, and evaluation. A
reader can follow the photograph feature throughout without first mastering the formal notation.
5
Page 6
Extracted text for page 6
Reaktor: An Extensible Software Engine Technical preprint
Established results are cited to primary literature or official system documentation. Repository
observations are attributed to a source revision or design inventory, not presented as independently
reproduced production evidence. Constructed application studies are explicitly scenarios. Where project
documents disagree, Appendix F records the scope decision adopted by this specification rather than
silently treating the corpus as a synchronized standard.
2 The engine model: mechanisms, Blueprints, and product composition
2.1 What the Unreal precedent actually establishes
Unreal Engine combines reusable runtime systems with authoring tools that expose those systems.
Blueprint Classes define reusable object behavior and can be instantiated in levels; Level Blueprints
coordinate level-specific events. C++ exposes functions and types to the visual language. The editor
can execute a selected instance, inspect values, and step through behavior [1, 11, 12]. This precedent
establishes a viable relationship among implementation, composition, and inspection. It does not establish
that application backends have the same execution or failure model as a game world.
The division of work has at least three levels. Engine engineers build foundational mechanisms such as
resource management, rendering, and networking. Gameplay developers build reusable systems such
as movement, inventory, or abilities. Level and experience designers combine assets and behaviors into
particular encounters. The boundaries are flexible: the same person can perform all three, and both C++
and Blueprints can be used beyond a rigid programming/scripting division [2].
Work Game-engine instance Reaktor instance
Mechanism engineering Resource loading, networking, object Runtime binding, FFI, synchronization,
lifetime delivery, state and update safety
Reusable system Inventory, movement, combat, abilities Media transfer, identity, messaging,
development approval, offline editing
Experience composition Encounters, level interactions, Screens, routes, product workflows,
configured actors policy parameters, customer-specific
assemblies
Operation and diagnosis Play-in-editor, instance inspection, Development profiles, typed probes,
traces feature traces, source-linked findings
Table 2: A division of engineering work, not a mandatory organizational hierarchy or division between humans
and machines.
For Reaktor, the reusable upload mechanism should own chunking, cancellation, resumability, and
its storage protocol. The conversation feature should own when upload occurs and how rejection is
presented. A designer can alter the preview and progression without editing transport code. A systems
engineer changes the underlying transfer mechanism when requirements demand a new capability. The
product-specific graph remains meaningful at both levels [3, 4].
2.2 Why a component library is not yet an engine
A library offers callable code. A template offers an initial copy of a project. A service catalog records
identities and relationships. Reaktor needs all three ideas, but its proposed reusable unit retains the
relationship between implementation and use. A component’s contract can connect to authoring controls,
runtime bindings, tests, diagnostics, deployment requirements, and update restrictions. A package update
can therefore be evaluated against the actual consumers of that package.
A feature package is a distribution unit containing an open module and its supported companions. It
may include alternate implementations, configuration schemas, examples, fixtures, source mappings,
6
Page 7
Extracted text for page 7
Reaktor: An Extensible Software Engine Technical preprint
operation descriptors, and assurance records. Installation does not imply that every feature can execute
everywhere. The package declares a support matrix and unresolved requirements. A mobile camera
implementation and a browser file-picker implementation may satisfy a common acquisition contract
while exposing different optional capabilities.
Unreal’s asset management, Game Feature plugins, and Gameplay Ability System provide related
industrial patterns: independently identified assets, explicit feature activation, and reusable mechanisms
that coordinate asynchronous behavior and effects [13, 14, 15]. Reaktor adopts the packaging and lifecycle
discipline, not gameplay-specific assumptions about authority, replication, or deterministic simulation.
2.3 Full-stack modules are distributed packages, not giant objects
A full-stack identity module can contain client sign-in adapters, shared credential-exchange contracts,
server verification, policy primitives, schema migrations, and diagnostic tools. Only the relevant parts
enter each target artifact. A browser must not receive server signing keys because both belong to the
same conceptual module. Likewise, a media package can contain a native acquisition adapter, a browser
adapter, an upload service contract, and a processing implementation without loading a server into the
mobile application [3, 16, 5].
The module graph separates logical ownership from build dependencies and deployed instances. A
feature imports a public module boundary. The build system selects compatible source sets and artifacts.
Deployment assigns those artifacts to execution domains. The system graph records the mapping. This is
the concrete meaning of one product spanning several runtimes.
Mechanism engineering
Typed contracts, implementations, lifecycle, diagnostics, obligations
Reusable feature packages
Media transfer identity offline state messaging workflows
Product composition
Readable source ↔ Blueprint authoring ↔ agent proposals
Realization and feedback
Mobile browser edge JVM data tests and observations
Figure 1: The engine’s reuse loop. Difficult mechanisms become composable vocabulary; product feedback
identifies which mechanisms need extension.
2.4 The human authoring contract
Composition is programming. A workflow author must understand its inputs, outcomes, ownership,
and permitted effects. A visual language does not remove that responsibility. It can reduce the amount
of implementation detail required to make a valid change and make some mistakes visible earlier. A
connection from an unauthenticated action to a protected effect should yield a precise finding, not a quietly
invalid line.
The same rule applies to agents. A registered operation is discoverable and typed, but selecting the
wrong legitimate operation remains possible. Package tests and constraints must be combined with
product acceptance criteria. The engine should help authors understand consequences rather than imply
that a successful connection proves the product correct.
7
Page 8
Extracted text for page 8
Reaktor: An Extensible Software Engine Technical preprint
Reaktor therefore has two complementary rates of change: mechanisms evolve under implementation
and compatibility discipline; compositions evolve within those mechanisms’ contracts. This is a design
policy, not a law that framework code changes slowly or that product code is always simple. New products
sometimes reveal a missing primitive. The engine is successful when implementing that primitive benefits
subsequent products without concealing its assumptions.
3 A feature from composition to production change
This constructed walkthrough uses a photograph message because it crosses the engine’s principal
boundaries. It is a specification of the intended integrated experience, grounded in the existing messaging,
media, actor, service, notification, and tooling designs; it is not a claim that the complete workflow already
ships [10, 3, 17, 18].
3.1 The product contract
The feature accepts a selected image and caption for a conversation. It preserves a draft across ordinary
interruptions, reports transfer progress, and distinguishes a locally queued submission from an accepted
message. Only an authorized participant may publish. Retries must not duplicate the protected
message-creation effect. A recipient can enter the conversation through a notification, subject to current
authorization.
These are product decisions. The engine does not derive them from a service signature. They become
explicit acceptance conditions attached to the feature. The walkthrough uses a server-readable media
policy so a processing service can inspect the image. An end-to-end encrypted policy is a different feature
configuration: server content inspection cannot coexist with a promise that the server never receives
plaintext or decryption keys (Section 20).
3.2 Choose the reusable mechanisms
The author installs or selects media acquisition, local drafts, transfer, messaging, notifications, and
instrumentation. A package catalog shows supported implementations and requirements. The mobile
profile binds acquisition to a native camera/gallery adapter; the browser profile binds it to a browser input.
Both return a managed media reference. Large image bytes need not traverse every graph port or pass
through a JavaScript object merely because the feature uses React.
The selected draft component exposes revisioned state. The transfer component owns transfer attempts
and cancellation. A messaging operation commits the authoritative message. Processing and notifications
subscribe to the appropriate durable facts. An application actor coordinates state changes that can arrive
concurrently from user actions, the network, and background execution.
3.3 Write the boundary and compose the behavior
A proposed shared interface exposes the product operation. Domain errors remain separate from transport
failures:
8
Page 9
Extracted text for page 9
Reaktor: An Extensible Software Engine Technical preprint
command
Photo composer Composer actor Messaging API Commit region
state + actions draft owner commit / result authority + outbox
Device store
Media transfer Object storage
draft /
submit / progress media reference
queued work
Recipient route Notification Publication
guarded entry subscription hyperedge
tap / entry
Analytics
subscription
Figure 2: The proposed feature at architectural scope. A component card summarizes owned ports; the commit
region includes the outbox relay. The publication card denotes one collective relationship, not a mandatory broker
component. Placement and observations are separate views of these identities.
@GraphService("example.photo-messaging")
interface PhotoMessagingApi {
@Operation("photo.commit")
val commit: Call<CommitPhoto, AcceptedPhoto, PhotoError>
}
data class CommitPhoto(
val conversation: ConversationId,
val media: UploadedMediaRef,
val caption: String,
val idempotency: IdempotencyKey,
)
The authenticated identity comes from trusted invocation context, not a caller-chosen user field. The
implementation still checks current conversation membership and media ownership. The stable operation
identity links caller ports, handler ports, source locations, compatible schemas, and transport bindings.
A Blueprint-style authoring surface can express the feature’s interaction sequence. The following is
proposed deeply embedded DSL notation: calls construct a program representation rather than immediately
performing an upload.
9
Page 10
Extracted text for page 10
Reaktor: An Extensible Software Engine Technical preprint
val photoSend = blueprint("conversation.photo.send") {
on(composer.submit) { draft ->
val valid = pure(validateDraft, draft)
branch(valid.accepted) {
whenTrue {
val uploaded = awaitCall(media.upload, draft.media)
match(uploaded) {
success { ref ->
val accepted = awaitCall(api.commit,
commitRequest(draft, ref))
emit(composer.result, accepted)
}
failure { error -> emit(composer.failure, error) }
}
}
whenFalse { emit(composer.validation, valid.problems) }
}
}
}
The graphical form exposes an event entry, a pure validation node, a branch, effectful calls, and outcome
ports. An unconnected required input remains visible as a typed hole. Replacing upload with a local
file reference is not valid merely because both can be represented as strings: their contracts differ. The
operational semantics and compilation obligations appear in Section 14.
The author can instead implement the behavior directly in Kotlin behind the same feature boundary.
The engine does not require a graph node for every expression. Arbitrary implementation bodies remain
ordinary source; only the supported declarative subset has a guaranteed visual correspondence. This
distinction preserves an escape hatch without falsely representing opaque code as completely known.
3.4 Bind the same logical feature to concrete profiles
A development profile chooses which components run locally, which use deterministic substitutes, and
which contact explicitly isolated remote resources. It also fixes application identity, data namespaces,
credentials, and effect permissions. A profile is not simply a URL suffix. The existing Shadow Dev design
identifies these cross-layer isolation requirements [18].
For an integration profile, the phone may call a local or development Worker, whose service binding
reaches another development Worker and whose Hyperdrive binding reaches a development Postgres
authority. A local JVM process can host an equivalent supported service implementation. Each choice is
recorded. The author sees which operations are simulated, which execute real code, and which leave the
machine.
Production uses real artifacts and resource bindings. The reference stack supplies Gradle/KMP outputs,
browser or Worker JavaScript, native libraries and mobile packages, JVM artifacts, and infrastructure/tool
operations. Reaktor’s planner connects the outputs; Gradle, platform toolchains, Wrangler, Fastlane,
Dagger, and Pulumi remain the executors of their respective steps [5, 19, 20, 6]. A generated plan is
inspected before a privileged operation is admitted.
3.5 What one declaration can produce
The shared operation plus its explicitly supplied descriptors can elaborate into several artifacts: The
intended reduction is in independently maintained facts. A route alias is not allowed to become a second
operation identity; a dashboard association need not repeat an unrelated string; a tool schema need not
invent another payload definition. Specialized external systems still retain their own native representations.
10
Page 11
Extracted text for page 11
Reaktor: An Extensible Software Engine Technical preprint
Input Derived output What is not inferred
Operation identity and schemas Endpoint descriptors, supported Correct business semantics
client/server bindings, source
navigation
Protocol and implementation Invocation plan, codec selection, Arbitrary location transparency
binding compatible transport options
Auth/effect requirements Enforcement wiring and coverage The intended authorization policy
obligations
Signal and test declarations Catalog entries, attribution, test Complete test coverage
associations
Artifact/resource requirements Build and deployment relationships, Cloud capacity or health without
missing-binding findings observation
Table 3: Derivation replaces duplicated descriptions only where the necessary inputs exist. A signature alone does
not generate a complete secure product.
3.6 Run and inspect the actual interaction
The author starts the selected execution profile and opens the composer. The inspector identifies the
logical feature, active implementation, source revision, current draft revision, and relevant invocation. A
progress stream is shown as a sequence with a known scope, not as a structural edit to the application. A
packet loss or server rejection can be injected only in a permitted test profile.
Suppose transfer finishes but the recipient sees no notification. The workbench follows the accepted
message to its outbox record, publication, subscription, attempt, and delivery outcome. A missing binding,
denied token scope, or incompatible consumer becomes a source-linked finding. If the evidence is
incomplete, the UI reports the missing observation; absence of an observed delivery is not proof that none
occurred. The same feature can be selected from the screen or the subscription without losing identity.
The result can become an incident capsule containing permitted inputs, revisions, relevant data
references, and comparison rules. Replay runs in an isolated environment with external effects intercepted.
Production data is not assumed safe because it has been copied or pseudonymized. The privacy and
materialization policy governs what enters the capsule.
3.7 Make a product change without rebuilding the mechanism
A product developer changes the preview layout and caption-validation behavior within a supported
Hermes region. LiveUpdate checks the host contracts, state compatibility, boundary closure, artifact
loader, and activation mode. The native shell and host-owned draft may remain installed while the feature
restarts at its next entry. Section 26 defines the conditions precisely.
A second change requests a native imaging capability absent from the host. The result is a required host
release, not a misleading successful CodePush. A third changes server policy and requires a compatible
backend rollout. The engine exposes all three as changes to the same feature, but does not pretend they
share one activation protocol.
3.8 The responsibility that remains
A feature composer decides the user journey, recovery affordances, and product policy. A mechanism
developer supplies a reliable transfer or authorization implementation. An operator approves deployment
into an authority scope. An agent can propose work, construct tests, or inspect evidence within its grant.
The shared graph coordinates these roles; it does not dissolve accountability or replace the external user’s
judgment of whether the feature is useful.
11
Page 12
Extracted text for page 12
Reaktor: An Extensible Software Engine Technical preprint
4 The concrete Reaktor reference stack
The architecture is extensible; its reference implementation is deliberately concrete. Reaktor’s source
organization centers on Kotlin Multiplatform modules, Compose and React surfaces, C++ and Hermes
interop, Cloudflare edge adapters, JVM services, and selected data and tool integrations. The modules are
not merely labels in a catalog: their public interfaces and implementations supply the vocabulary from
which application graphs are built [3, 21, 5].
4.1 Source sets, runtimes, and products are different axes
Kotlin commonMain is a shared source set, not an independently executing machine. Android/JVM,
Kotlin/Native on iOS, browser JavaScript, Worker JavaScript, and Hermes-hosted JavaScript have
distinct execution conditions. C++ can participate through native bindings. Compose and React are
authoring/rendering ecosystems, not deployment locations. A reference profile identifies each axis
separately so “runs on web” does not imply compatibility with Worker APIs or with every JavaScript
engine.
A product contains modules; a build selects source sets and dependencies; artifacts implement particular
module revisions; runtime instances execute those artifacts. The physical application may therefore
contain only the client side of a full-stack module, while the corresponding service and operational tooling
execute elsewhere.
Table 4: Reference stack and its relation to the system model. Implementation status is source-reported and scoped
in Appendix F.
Area Reaktor surface Concrete realization and graph contribution
Foundation reaktor-core; graph Feature slots, platform adapters, lifecycle,
modules typed owned ports, scoped node composition
Mobile App graphs; UI, media, work, Android and iOS hosts, native callbacks and
auth, notification modules permissions, local state, packaging and
device tests
Web Kotlin/JS graph; React Browser history, DOM rendering, state
bindings; web hosts subscriptions, web storage and
browser-specific capabilities
Services reaktor-service; Shared operations and handlers; Ktor client,
ServiceNode Spring WebFlux routing, Hono Worker
mounting
Edge reaktor-cloudflare Worker contexts and bindings for services,
D1, Durable Objects, R2, KV, Hyperdrive
and related APIs
Core backend JVM/Spring targets; JVM artifacts and k3s/GCP deployment;
Google/cloud adapters typed calls, stores, credentials, Pub/Sub
adapter
Data reaktor-db; descriptor SQLDelight/SQLite, Postgres, Memgraph,
design R2 and analytical projections; authority,
sync, lineage and freshness
Language reaktor-ffi; FlexBuffer JNI, cinterop, JSI/Hermes experiments and
boundary proposed Switchboard protocol; ownership
and ABI descriptors
12
Page 13
Extracted text for page 13
Reaktor: An Extensible Software Engine Technical preprint
Area Reaktor surface Concrete realization and graph contribution
Build Dependeasy; Reaktor CLI Gradle/KMP/native conventions and task
discovery; artifacts, toolchains, target
metadata and task operations
Deployment reaktor-cloud; DevOps Dagger, Pulumi, Wrangler, k3s and mobile
plane release tooling; desired resources, operation
receipts and observed state
Observation Telemetry/performance OTel, analytics sinks, platform profiler/test
modules reports, graph attribution, budgets and
operational findings
Workbench Engine module; desktop/web Shared pane graphs and domain state;
targets Compose/React renderers, source navigation,
inspection and command interfaces
4.2 The smallest useful profile
A solo developer should be able to use an in-process graph, a native or browser UI, a local store, and the
ordinary build tooling. No cloud-cell agent, distributed graph registry, broker, or LLM is required. A
service can initially bind to a local implementation. The developer can inspect owned dependencies and
use shared contracts even before adopting advanced deployment or verification facilities.
Adding a backend introduces an explicit call boundary, authenticated context, and a chosen data
authority. Adding durable fanout introduces a bus profile and its operational dependencies. The engine’s
packaging must make these additions visible in binary size, memory, configuration, and maintenance cost.
The reference stack is a menu of supported profiles, not a requirement that every application deploy every
listed store.
4.3 One shared operation on real service hosts
The existing BestBuds API uses an abstract MessagingApi with typed handler properties. Client
implementations and test implementations agree on that API. The proposed graph contract preserves this
authoring agreement while separating operation identity from HTTP method and route. The latter belong
to exposure and transport descriptors [10, 22].
The existing authoring pattern can be seen in the messaging source:
// Excerpt from the pinned BestBuds source; other members omitted.
abstract class MessagingApi(baseUrl: String = "") : Service(baseUrl) {
abstract val sendMessage:
PostHandler<MessagingRequest.Send, MessagingResponse>
}
Section 11 retains the shared member contract while making Call and its outcome independent of the
HTTP-specific handler type. This is a proposed evolution of an existing interface pattern, not a separate
hand-maintained operation registry.
On the JVM, a host mounts supported handlers through Spring routing. On Workers, the Cloudflare
adapter mounts handlers through Hono and supplies a Worker context. Worker-to-Worker service bindings
are another realization; the currently documented Reaktor wrapper and a future typed RPC binding must
not be conflated. Cloudflare itself supports both fetch-style and RPC service bindings, whose execution
and context-propagation rules remain relevant to the adapter [23, 24].
13
Page 14
Extracted text for page 14
Reaktor: An Extensible Software Engine Technical preprint
A deployment view should identify the operation, the selected handler artifact, the host entrypoint, its
required resource bindings, and the associated tests. It should not merely display a node called “Cloudflare.”
A missing media bucket is a failed resource requirement; a missing downstream authorization context is a
failed invocation requirement. They require different remedies.
4.4 The difference between existing slices and the complete engine
The source inventories report functioning graph composition, shared service handlers, local actors, stores,
platform adapters, build conventions, and portions of the workbench. They also identify incomplete or
unimplemented capability normalization, general Blueprint execution, graph-native bus/mesh, complete
provider federation, Switchboard, host-tree interop, and LiveUpdate. A working native bridge experiment
is evidence for a boundary, not evidence for safe dynamic replacement [21, 22, 25, 26, 4, 8].
The workbench itself is an instructive implemented slice: the engine module carries shared domain
state and graph structure, with Kotlin/React and Compose rendering paths. Some service interfaces are
still mock-backed. The report therefore supports code and model reuse, not the claim that every displayed
cloud or agent action operates a production backend [27].
4.5 One authority for each authored fact
Application source owns declarations. Supported Blueprint edits are serialized through the owned source
representation. Infrastructure configuration owns desired resources unless a declared generator owns
that region. Provider APIs report observations. Build tools report outputs and dependencies. A system
snapshot records the selected revisions and provenance of these facts; it does not silently supersede them.
The graph is thus authoritative for its compiled semantic revision while remaining derived from
explicitly owned inputs. This resolves an apparent contradiction between “the graph is the application”
and “code remains truth”: for the supported language, source and graph denote the same program; for
imported or arbitrary code, the graph describes only the relationships its provider can establish. The
knowledge model preserves that difference.
5 Blueprint authoring and reusable feature packages
A Reaktor Blueprint is a supported executable program over graph components, not a second drawing
database. The project design distinguishes structural application graphs, behavior Blueprints, workflow
graphs, UI render trees, and observational overlays. These share identities and mappings but have different
semantics [4, 28]. A structural connection makes a capability available; it does not by itself schedule a
call. A behavior graph determines when an operation is invoked. A render tree describes a surface. A
trace records a particular execution.
5.1 Visual grammar
The editor must make the distinction between connectivity and execution readable. Node cards expose
typed ports; a port tooltip reports signature, role, protocol, binding state, and relevant requirements.
Exec wires express ordering or selected control transfer in a behavior dialect. Data wires express value
dependencies. A stream or session is not drawn as a permanently available scalar. A group relationship
retains its hyperedge identity rather than appearing as unrelated pairwise arrows.
An incomplete graph remains editable. A missing input is displayed as a typed hole with a finding; an
invalid operation is not silently dropped. The palette can narrow candidates to compatible signatures and
available implementations. That is assistance, not proof that a suggested operation expresses the author’s
intent. Conversions appear as explicit adapter nodes when they change a value’s meaning or introduce a
possible failure.
14
Page 15
Extracted text for page 15
Reaktor: An Extensible Software Engine Technical preprint
Surface Meaning Permitted edit
Structural graph Components, owned ports, module A validated structural/source patch
boundaries and bindings
Behavior Blueprint Events, values, branches, loops and A program edit with dialect-specific
effects checks
Workflow graph Durable steps, outcomes, retries and A definition change with
compensation execution-version constraints
UI surface Owned component tree, properties, A supported authoring or host-tree
actions and layout operation
Deployment lens Artifacts, placement, resources and A plan, not an immediate arbitrary
realization runtime mutation
Observation overlay Instances, attempts, metrics and Read-only evidence, plus explicit
findings authorized operations
Table 5: The same workspace supports different semantic views. Hiding an authorization overlay does not disable
authorization.
View metadata—positions, collapsed groups, active tabs and bookmarks—is separate from program
semantics. Dragging a card across the canvas must not redeploy its component. Moving a component
between execution domains is an explicit placement edit with a visible consequence and a different
permission requirement.
5.2 One supported program, two authoring surfaces
A deeply embedded DSL builds a representation of operations and control flow. A call to a DSL
constructor records a node rather than performing the effect during graph construction. This gives
the editor, interpreter, compiler, and agent a common program to inspect. Ordinary Kotlin inside an
implementation body remains ordinary Kotlin; the visual round-trip guarantee does not extend to arbitrary
language constructs merely because they appear inside a builder.
Let 𝑆 be a supported source representation, 𝐸 (𝑆) its elaborated program, and 𝑃 a printer for that
program subset. The target round-trip obligation is
𝐸 (𝑃(𝐸 (𝑆))) ≡ 𝐸 (𝑆), (1)
where equivalence preserves stable declarations, binding meaning, and program behavior under the
selected dialect. It need not preserve whitespace. Comments and manually owned source regions require
a source-preserving editing strategy or an explicit boundary around generated regions.
Visual edits therefore follow an explicit sequence: resolve the selected source revision, propose a
semantic change, generate the corresponding source change, elaborate again, and compare the actual
semantic delta with the approved intent. Generated implementation code is an artifact unless the project
explicitly transfers ownership to it. Two independently editable authoritative forms would recreate the
drift the architecture is intended to remove.
The project proposal describes push-exec/pull-data evaluation. Reaktor adopts this as one behavior
dialect, not as a universal definition of flow-based programming or Kahn networks. IO belongs to effectful
nodes. Pure expression results may be cached only within an evaluation scope whose inputs and observed
state revision are fixed. A loop iteration that changes state creates a new relevant evaluation context. These
refinements prevent a visually pure-looking node from silently performing a network read or returning
stale memoized state [4, 29, 30].
15
Page 16
Extracted text for page 16
Reaktor: An Extensible Software Engine Technical preprint
Draft snapshot Draft Build request
revision 𝑣 pure function
CommitPhoto
exec exec Apply typed
Submit event CommitPhoto call
outcome
CallOutcome
Figure 3: A behavior Blueprint uses distinct execution and value connections. Solid execution wires sequence
effects; dashed value wires supply typed values. The call’s infrastructure and domain outcomes remain explicit.
Visual position carries no execution meaning.
5.3 Reusable definitions, instances, and parameterization
A feature definition specifies a boundary and internal composition. Each mounted instance has its own
scoped identity and state ownership. Two instances of an upload feature cannot share mutable draft state
merely because they reuse the same definition. Definition revisions and instance identities are separate,
just as logical components and runtime activations are separate.
A product can configure exposed parameters, bind required ports, and select supported implementations.
It cannot mutate another module’s internals through an undeclared editor gesture. An exceptional
change becomes an explicit extension, fork, or implementation replacement with visible maintenance
responsibility. This preserves reuse without forcing all products into one inflexible template.
A proposed package descriptor has the following shape:
data class FeaturePackage(
val identity: PackageId,
val revision: ContentHash,
val module: ModuleDescriptorRef,
val implementations: List<ImplementationDescriptorRef>,
val authoring: AuthoringDescriptorRef?,
val fixtures: List<TestFixtureRef>,
val operations: List<OperationDescriptorRef>,
val evidence: List<EvidenceRef>,
)
The optional companions are deliberate. A pure library need not ship a workbench panel. A high-level
feature intended for visual composition should normally supply configuration schemas, examples, failure
outcomes, and source mappings. An extension becomes useful to agents through the same discoverable
descriptors rather than a separately maintained prompt fragment.
5.4 What the author still programs
Reusable components absorb repeated mechanisms, not every decision. The author chooses which events
initiate work, how outcomes change the product state, which approvals matter, what data is authoritative,
and how failure appears to users. A reusable payment integration cannot determine whether a particular
business should refund an order. A workflow compiler cannot infer the legal meaning of an approval from
a boolean port.
The Blueprint layer should make the common path compact while retaining the underlying graph and
contract APIs. Pure functions, reducers, and specialized algorithms can remain textual implementations.
Algorithms with dense mathematical notation may be clearer in source than as hundreds of boxes. A
feature’s visual boundary can still expose those implementations for composition and diagnosis.
16
Page 17
Extracted text for page 17
Reaktor: An Extensible Software Engine Technical preprint
5.5 Versioning the authoring vocabulary
Adding a new node kind requires more than a palette icon. The extension declares pin schemas, behavioral
semantics, lifecycle, supported realizations, diagnostics, and migration behavior for persisted definitions.
An old editor may inspect an unknown node as opaque metadata, but cannot silently execute it or claim its
validation rules ran. An updated package must not reinterpret an existing saved graph without a versioned
migration.
Assurance evidence attaches to a package revision, its implementations, and the assumptions required
by its consumers. A guarantee about one implementation is not inherited by every implementation of
the same interface. Section 29 explains how such extensions expand the feasible system space while
preserving a usable distinction between composition and mechanism engineering.
6 The workbench: edit, run, inspect, and explain
Reaktor Desktop and the web workbench are authoring and operational surfaces over the engine. They
should not be collections of independently maintained diagrams and dashboards. A selection identifies
a logical entity, source revision, execution context, and optionally a runtime instance; changing views
preserves that identity [31, 27, 8].
6.1 Navigate by scope, not by rendering the entire universe
The default view presents the selected scope and its immediate boundary. At product scope, apps, services,
external systems, stores, and operational resources are visible. Opening an app reveals its feature modules.
Opening a feature reveals components and typed ports. Opening a behavior reveals its executable program.
A source action resolves the corresponding declaration or implementation. This follows the hierarchy
discipline of C4 while retaining Reaktor’s executable and operational semantics [32, 31].
Zoom changes the level of explanation, not just the size of text. A high-level service card summarizes
its boundary, status, and relevant findings. A trace lens can temporarily expand the path needed to explain
one invocation. A data lens follows authorities and projections. An authorization lens shows requirements
and enforcement points. Display filters do not alter the underlying program or disable mandatory policy.
The physical visualization model belongs to compose-flow/reaktor-flow or the web renderer.
Selection indexes, viewport culling, edge routing, and accessible keyboard navigation are renderer
responsibilities. They consume semantic IDs; canvas coordinates are never the identity of a service [33].
6.2 A shared authoring session
An author selects the photograph feature, opens its preview, and chooses a development profile. The
property panel exposes only declared configuration and source-owned parameters. A context menu can
locate compatible components, open source, show the operation contract, run an associated check, or
propose a change. Each action distinguishes inspection from mutation and shows its applicable authority
scope.
The source editor remains a first-class route into the system. A textual refactoring updates the graph
after elaboration; an unsupported semantic change is shown as an ordinary source diff with reduced graph
knowledge. A visual edit does not need an LLM to translate a known structural operation. Deterministic
transformations should remain deterministic. Agents are useful for reasoning and implementation that
exceed the supported edit grammar.
17
Page 18
Extracted text for page 18
Reaktor: An Extensible Software Engine Technical preprint
6.3 Four different meanings of debugging
Unreal’s Blueprint debugger provides breakpoints, value inspection, execution traces, and call-stack
navigation during controlled editor execution [12]. Reaktor needs comparable feedback, but distributed
systems require distinct modes:
Mode Available evidence/control Boundary
Local debugging Breakpoints, state, source and invocation A paused process does not pause remote
inspection dependencies
Controlled simulation Virtual clocks, seeded inputs, fault Reproducibility depends on modeled
schedules, deterministic adapters nondeterminism
Remote observation Traces, logs, metrics, snapshots, Sampling and staleness remain visible
authorized probes
Isolated replay Captured inputs and permitted state External effects are intercepted; replay is
against a selected branch not production mutation
Table 6: Debugging capabilities are profile-specific. A global pause across an uncontrolled distributed fleet is not
assumed.
A watched value records its invocation and state revision. A value left on a wire from a previous
execution must not look current. A graph breakpoint at a network boundary cannot retract an already
committed remote effect. Actor inspection must not mutate internal state outside the mailbox. These
rules make familiar visual debugging useful without importing misleading local-execution assumptions.
6.4 Findings are explanations attached to work
A finding identifies a rule, affected entities, source locations, evidence, and possible remedies. Examples
include an unbound provider, unsupported codec, missing tenant enforcement, unfulfilled host requirement,
stale data projection, or incompatible update group. The explanation should expose the relevant path or
counterexample rather than a generic red badge.
A proposed patch carries source and semantic diffs together. The reviewer can see the affected contracts,
deployment resources, tests, and assurance obligations. An operation receipt links to the command
actually executed and distinguishes acceptance from observed completion. The workbench does not
synthesize a successful state from a button press or an agent’s prose claim.
6.5 Self-hosting as a useful but limited case
The engine/website report describes a shared workbench core with pane graphs, services, repositories,
actors, and renderer-facing state used by Compose desktop and Kotlin/React web surfaces. This is a
concrete example of Reaktor composing its own tooling [27]. It tests hierarchical navigation, cross-view
selection, and model reuse. It is not proof that all mock-backed operations have real executors or that a
workbench is easy for an unfamiliar team to adopt. Those questions belong to the evaluation.
7 A shared model across authoring, execution, and observation
Reaktor separates the logical system, its physical realization, and evidence about its operation. Figure 4
shows the principal flow. Source declarations, schemas, and configuration providers elaborate into a
versioned logical model. Compilers and planners derive executable and deployment projections. Runtime
providers report observations that remain distinct from desired state. Human and agent tools operate
through the same query and change contracts.
18
Page 19
Extracted text for page 19
Reaktor: An Extensible Software Engine Technical preprint
Source, contracts, Logical port graph Deployment and
configuration and semantic aspects execution plans
Human and agent Observations, lineage, Applications, services,
queries and patches tests, proof evidence data and cloud resources
Figure 4: A shared semantic model with distinct authoring, execution, and observation paths. Feedback proposes
changes; observations do not silently overwrite declared intent.
7.1 Planes and identities
The logical plane contains components, owned interfaces, executable edges, behavior definitions, and
module boundaries. Semantic aspects add relationships such as authorization, navigation, ownership,
and data lineage. The deployment plane assigns implementations and artifacts to execution domains and
resources. The observation plane describes instances, invocations, delivery attempts, state revisions, and
measured behavior.
These are orthogonal dimensions rather than a product of every possible “layer.” An authorization aspect
may apply to components on a device and a server. Production and development are deployment contexts.
A trace is an execution observation, not a new copy of the application architecture. Multilayer-network
terminology provides a useful distinction between shared entities and relations that differ by aspect;
Reaktor does not require identical node sets in every aspect [34].
Stable identities distinguish logical entities, artifacts, deployments, runtime instances, and individual
activations. A service restart changes its runtime instance, not the logical operation identity. Replication
produces several instances of one logical component. A new implementation artifact can preserve an
interface while changing internal source locations. Aliases are explicit and attributable; similar names are
not sufficient evidence that two imported entities are identical.
7.2 Authority and revisions
Each source has authority over declared classes of facts. Application source owns native declarations.
Infrastructure configuration owns desired resources. Provider APIs report observations. A schema registry
owns published contract revisions. The system registry retains these claims with their provenance rather
than resolving disagreement through unrestricted last-write-wins merging.
A project revision records a coherent selection of source and contract revisions. A federated view
additionally records source watermarks and observation times. Neither record implies a globally
simultaneous snapshot of a distributed fleet. Analyses requiring a consistent cut must obtain one or
explicitly state a weaker observation model.
The existing unified-system-graph and data-layer documents motivate provider fragments, desired/ob-
served separation, and authority-versus-projection relationships [35]. This specification makes those
distinctions part of the model rather than workbench-only display conventions.
7.3 Control and execution
Authoring operations create proposals. Validated proposals may commit a semantic revision. Deployment
operations reconcile the selected revision with external systems. Runtime invocations execute precompiled
bindings. These paths share contracts and identities, but not necessarily schedulers, privileges, or storage.
A product application must not acquire deployment or administrative capabilities merely because
its operation types are also used by workbench tools. Control-plane operations belong to an explicit
management scope. A headless build or manually authored application can use the architecture without
an agent or visual editor.
19
Page 20
Extracted text for page 20
Reaktor: An Extensible Software Engine Technical preprint
8 Mathematical foundations for architectural reasoning
A mathematical model is useful when it removes ambiguity that would otherwise become an implementation
bug. The purpose of the following vocabulary is therefore operational. A function makes ownership
single-valued. A relation represents potentially many dependencies. An invariant restricts every permitted
state. A partial order distinguishes causality from an arbitrary display order. A refinement states what an
implementation must preserve when its representation changes. Standard treatments of sets, relations,
induction, and state machines supply the basic background [36].
8.1 Sets, identities, functions, and relations
A set specifies which entities exist in a model. Identity is membership in the set of entities, not the entity’s
display name or memory address. Two services called billing may belong to different tenants. Two
running replicas can implement one logical service. A release can change an implementation without
changing the operation it implements. These distinctions should be reflected in the identifier types before
any graph algorithm is introduced.
A function 𝑓 : 𝑋 → 𝑌 gives exactly one result for every member of 𝑋. The ownership function
𝑜 : 𝑃 → 𝑁 therefore says that each port has exactly one node owner. It does not say that a node has only
one port, because several inputs to a function may map to the same output. An injective function maps
different inputs to different outputs. An interface exposure map can be injective when each exposed entry
names a distinct port.
A relation 𝑅 ⊆ 𝑋 × 𝑌 can associate one entity with several others or none. Placement eligibility, test
coverage, and data derivation are naturally relational. A chosen placement might subsequently become a
function from a particular runtime instance to its execution domain. Eligibility and the chosen plan must
not be confused: the former describes allowed alternatives, the latter a decision.
For a finite example, let 𝑁 = {𝑢, 𝑠} be a user-interface component and a service. Let 𝑃 = {𝑐, ℎ} be their
caller and handler ports, with 𝑜(𝑐) = 𝑢 and 𝑜(ℎ) = 𝑠. A connection between 𝑐 and ℎ is an entity with its
own identity. Its request schema, cancellation behavior, and chosen transport are not additional owners of
either port. A database table can store all four records centrally and still preserve these functions exactly.
8.2 Types distinguish legal objects from merely encodable objects
A storage system can encode a port connected to a source file or an authorization policy used as a network
address. That does not make either relationship legal. A type schema states the permitted entity kinds,
fields, relationships, and endpoint roles. A typed instance must satisfy that schema.
At the simplest level, a type predicate can establish that an edge has one caller and one handler. A richer
contract can state that the caller sends values the handler accepts. These are different obligations. Exact
type identity is an easy sufficient compatibility rule, but versioned schemas often require a directional
compatibility relation. For request/reply, the handler must accept the caller’s possible requests, while the
caller must understand the handler’s possible results. A broad error union accepted by both parties may
simplify evolution; silently replacing a result schema does not.
Behavioral types add ordering information. A session that permits Open, then several Item messages,
then Close cannot safely receive Item before Open. Session-type research formalizes communication
sequences and role compatibility [37]. Reaktor’s initial standard profiles should use small explicit
state machines. General multiparty protocol checking is an extension with its own assumptions, not an
automatic consequence of a typed payload.
20
Page 21
Extracted text for page 21
Reaktor: An Extensible Software Engine Technical preprint
8.3 Partial orders, causality, and information growth
A partial order ⪯ is reflexive, antisymmetric, and transitive. Unlike a total order, it need not compare
every pair. Two unrelated events in different services may be concurrent. Imposing an arbitrary sort order
for a timeline is useful for display but does not establish causality.
The same mathematical notion describes growing information. A partial graph fragment can contain
fewer established facts than a larger fragment. Under an information order, acquiring more facts moves
upward. It must not retroactively turn an unobserved event into a proven absence. In particular, the
absence of a service call in sampled traces means only that the sample did not include it.
Monotonicity means preserving an order: 𝑥 ⪯ 𝑦 implies 𝑓 (𝑥) ⪯ 𝑓 (𝑦). If a query only accumulates
possible dependencies as new facts arrive, it is monotone with respect to set inclusion. A query for
“components with no outgoing calls” is not: a later observation can invalidate an earlier result. This
distinction affects caching, incremental proofs, distributed computation, and the permissions granted from
incomplete knowledge. CALM relates monotonicity to coordination-free consistency under a particular
distributed-computation model; it is not permission to ignore application invariants [38, 39].
8.4 Fixed points and closure
A fixed point of 𝑓 is a value 𝑥 for which 𝑓 (𝑥) = 𝑥. Many architecture analyses repeatedly add consequences
until nothing changes. To determine a live-update region, begin with changed entities, add unmediated
lifetime dependencies and mandatory co-update partners, and repeat. To determine the impact of a schema
change, repeatedly follow the relationships selected by that analysis.
Let 𝑉 be a finite entity set, 𝑆 ⊆ 𝑉 the initial selection, and 𝐷 ⊆ 𝑉 × 𝑉 the dependency relation for a
particular closure. Define
𝐹 (𝑋) = 𝑆 ∪ 𝑋 ∪ {𝑣 | ∃𝑢 ∈ 𝑋 : (𝑢, 𝑣) ∈ 𝐷}. (2)
Starting at 𝑋0 = 𝑆 and setting 𝑋𝑖+1 = 𝐹 (𝑋𝑖 ) produces a growing sequence.
Proposition 8.1 (Finite closure). The sequence reaches a fixed point after at most |𝑉 \ 𝑆| strict expansions.
Its limit is the least set containing 𝑆 and closed under 𝐷.
Proof. Each strict expansion adds at least one previously absent member of the finite set 𝑉. At termination,
every dependency successor is already included. Any other closed set containing 𝑆 contains 𝑋0 and,
inductively, every 𝑋𝑖 ; it therefore contains the limit. □
The proposition says nothing about whether 𝐷 is the correct dependency relation. A closure over
imports alone can omit captured callbacks or shared state. The domain analysis must establish which
relationships are required.
8.5 State machines, invariants, and traces
A transition system consists of possible states and permitted transitions. An execution is a sequence of
states connected by those transitions. An invariant 𝐼 holds in every reachable state. Induction gives the
usual proof pattern:
𝐼 (𝑥 0 ), 𝐼 (𝑥) ∧ 𝑁𝑒𝑥𝑡 (𝑥, 𝑥 ′ ) ⇒ 𝐼 (𝑥 ′ ). (3)
The first condition establishes the invariant initially. The second establishes that every allowed step
preserves it. Checking only the successful path is insufficient when failure, cancellation, retry, or
concurrent mutation is also allowed.
A trace records observable actions, possibly hiding internal transitions. A caller may observe that
its request was accepted and later receive a result without seeing a serializer allocation or a routing-
table lookup. This distinction allows an optimized implementation to differ internally from a simple
21
Page 22
Extracted text for page 22
Reaktor: An Extensible Software Engine Technical preprint
specification. A trace-refinement claim restricts observable behavior; additional arguments are needed for
progress when an implementation could perform internal actions forever [40, 41].
8.6 Compositional reasoning and its limits
The attraction of modules is that a large proof should not require reopening every implementation detail.
An assume–guarantee contract states that a component provides guarantee 𝐺 when its environment
satisfies assumption 𝐴. Composition must show that the surrounding components really establish 𝐴.
For example, a consumer may guarantee bounded memory if the producer honors a credit protocol.
The producer’s guarantee must refer to the same credit ownership and message-loss assumptions. If both
sides merely assume the other eventually acts, neither has established progress. Cyclic assumptions need
a justified temporal argument, not a diagram in which the arrows happen to form a cycle.
Category-theoretic composition makes interfaces and combinations mathematically explicit. A category
supplies objects, composable arrows, identities, and associativity. In an open-system interpretation,
objects describe boundaries and arrows describe systems exposing those boundaries. A symmetric
monoidal structure additionally represents placing systems side by side. These laws justify rearranging a
composition expression without changing its meaning, provided the selected formal construction actually
has those laws [42, 43].
Reaktor need not expose categorical terminology in application APIs. The practical consequence is
that module nesting, flattening, and wiring must agree on a defined boundary semantics. An identity
adapter must not introduce a hidden policy change. A compiler that fuses two modules must preserve the
effects visible outside their combined boundary.
8.7 Mathematics as an engineering interface
The value of these concepts is visible in implementation decisions. Total ownership functions become
non-null owner references plus validation. Incidence occurrences become explicit records. Fixed-point
analyses become worklists. Partial orders become causal or revision tokens. Invariants become admission
checks and proof obligations. Refinements become contracts between source IR, storage, generated code,
and runtime adapters.
The correspondence is not automatic. A Kotlin type declaration may describe a property that a
deserializer can violate. A graph validator may omit a mutation path. A proof may reason about
unbounded integers while runtime counters wrap. Each representation boundary therefore needs a stated
mapping and either a proof, a check, or an acknowledged trust assumption. Formal structure improves
engineering precisely because it exposes these obligations.
9 The graph-theoretic model
9.1 Typed incidence structure
Definition 9.1 (Port multihypergraph). At a fixed revision, the structural model is
𝐻 = (𝑁, 𝑃, 𝐸, 𝐽, 𝑜, 𝑎, 𝑏, 𝑟, 𝜏, 𝐹), (4)
where 𝑁, 𝑃, 𝐸, and 𝐽 are disjoint finite sets of nodes, ports, edges, and incidence occurrences. The total
functions
𝑜 : 𝑃 → 𝑁, 𝑎 : 𝐽 → 𝐸, 𝑏:𝐽→𝑃 (5)
give port ownership and incidence attachment. The map 𝑟 : 𝐽 → Roles assigns incidence roles. The
family 𝜏 assigns node, endpoint, and edge types. The family 𝐹 contains schema-checked attributes.
22
Page 23
Extracted text for page 23
Reaktor: An Extensible Software Engine Technical preprint
For 𝑥 ∈ 𝐸, let 𝐽 𝑥 = { 𝑗 ∈ 𝐽 | 𝑎( 𝑗) = 𝑥}. A binary edge has |𝐽 𝑥 | = 2; a hyperedge may have any arity
admitted by its type. Edge identity is independent of its endpoints, so parallel edges remain distinct.
Incidence occurrences preserve repeated positions and separately configured memberships; replacing 𝐽 𝑥
with an unlabeled set of ports would lose this information.
Ports are semantically owned by nodes:
∀𝑝 ∈ 𝑃, ∃!𝑛 ∈ 𝑁 : 𝑜( 𝑝) = 𝑛. (6)
Central storage of port records does not alter this ownership relation. A graph is the container and
authority for a revision; a node remains the owner of its interface.
Attributed hierarchical port graphs provide a precedent for nested port structure and rewriting [44].
Annotated hypergraphs provide a precedent for roles in multi-party relations [45]. The present construction
adds software-specific typing and interpretation; theorems about either precedent require an explicit
encoding before they apply.
9.2 Typing and structural validity
A type schema specifies admissible node kinds, endpoint signatures, protocol roles, edge profiles, and
attribute domains. Every incidence must be compatible with both its endpoint type and its edge role.
Distinct occurrences can refine a generic endpoint role into named participants, such as a coordinator, an
input position, or a subscription membership.
Let Valid𝑠 (𝐻) denote structural validity. It includes total ownership, referential integrity, type
compatibility, role constraints, cardinality constraints, unique identities, and module-boundary rules. It
does not imply arbitrary business correctness. A cyclic dependency is not globally forbidden: feedback,
recursion, and stateful communication can be legitimate. Particular dialects may require acyclicity or an
explicit delay on cycles.
9.3 Protocols determine direction and enablement
An edge is structural. Its interaction profile supplies an interpretation
𝜂(𝑥) = (Π 𝑥 , 𝜒𝑥 , 𝛿 𝑥 , 𝜅 𝑥 ), (7)
where Π 𝑥 is a protocol, 𝜒𝑥 coordination behavior, 𝛿 𝑥 delivery and buffering behavior, and 𝜅 𝑥 a set of
requirements. The implementation may intern this descriptor; the notation does not require a separate
runtime object per field.
For lane ℓ of an edge protocol, derive source and destination incidence sets 𝑇𝑥,ℓ , 𝐻 𝑥,ℓ ⊆ 𝐽 𝑥 . A
request/reply edge has caller-to-handler request traffic and handler-to-caller outcomes. Cancellation and
demand can have additional directions. Dependency orientation is a separate projection.
A hyperedge does not imply that every participant must be ready simultaneously. A broadcast, an
anycast operation, and an AND-join can share an incidence shape while having different enablement rules.
Directed-hypergraph algorithms therefore require the relevant path and enablement semantics [46]. An
ordinary breadth-first traversal of an incidence projection establishes structural adjacency, not protocol
progress or the feasibility of a join.
9.4 Incidence encoding and representation correctness
Proposition 9.2 (Lossless incidence encoding). A finite port multihypergraph has a lossless typed-graph
encoding with 𝑂 (|𝑁 | + |𝑃| + |𝐸 | + |𝐽 |) structural records, plus the storage for encoded identities, types,
and attribute payloads, provided incidence occurrences, ownership, and roles are retained.
23
Page 24
Extracted text for page 24
Reaktor: An Extensible Software Engine Technical preprint
Proof. Create typed vertices for the elements of 𝑁, 𝑃, 𝐸, and 𝐽. Encode 𝑜 as one labeled ownership
arc per port. Encode 𝑎 and 𝑏 as two labeled arcs per incidence, and store 𝑟, 𝜏, and 𝐹 as typed labels or
attribute records. The four vertex sorts and the functional arcs uniquely recover the original sets and
maps. Decoding therefore recovers 𝐻 up to an identity-preserving isomorphism. The number of structural
records and arcs is linear in the four set sizes; variable-length metadata contributes its own encoded
size. □
This encoding permits conventional graph tools without treating an edge as a software component. A
specialized storage layout may omit explicit incidence vertices for binary edges if its decoder reconstructs
them without ambiguity. Correctness requires
decode(encode(𝐻)) 𝐻, (8)
not equality of physical row order or object addresses.
9.5 Hierarchy and exposed interfaces
Definition 9.3 (Open module). An open module is 𝑀 = (𝐻, 𝐵, 𝛽), where 𝐵 is a finite set of named
boundary endpoints and 𝛽 : 𝐵 ↩→ 𝑃 is an injective map selecting exposed owned ports. Multiple public
names for one endpoint are represented as aliases, rather than separate boundary incidences.
A hierarchical module associates an internal graph with a composite node in its parent scope. The
composite node owns its façade ports. An explicit boundary map relates those ports to internal endpoints.
No port acquires two owners. Flattening preserves identities or supplies a total provenance map from
flattened entities to hierarchical origins.
Composition takes disjoint module interiors and adds typed boundary connections. It does not identify
two ports with different owners as a single port. Open-graph composition and rewriting provide relevant
foundations [43, 42]; exact categorical constructions depend on the chosen boundary and type encoding.
Proposition 9.4 (Ownership-preserving composition). Let two structurally valid modules have disjoint
entity identities. If a composition adds only well-typed edges and incidences on permitted boundary
endpoints, preserves all endpoint cardinality bounds, and does not change ownership, then total unique
port ownership and the stated local structural constraints are preserved.
Proof. The disjoint union preserves each module’s ownership function without identifying its domain or
codomain elements. Added incidences reference existing ports and new edges, so referential integrity
follows from their construction. The assumptions discharge typing, cardinality, and boundary obligations
for the new records; existing records are unchanged. □
The proposition does not establish global security, deadlock freedom, or resource sufficiency. Such
properties need additional composition rules or a check of the composed system.
9.6 Behavioral interpretation
The execution interpretation of a graph is a labeled transition system
⟦𝐻⟧ = (𝑋, 𝑋0 , A, −→), (9)
whose state includes component state, buffers, active calls, sessions, ownership epochs, and the se-
lected topology revision. Node and edge profiles contribute transitions. Local actions interleave
with communication and environmental actions; this semantics does not prescribe a single-threaded
implementation.
24
Page 25
Extracted text for page 25
Reaktor: An Extensible Software Engine Technical preprint
A transition can send, admit, deliver, acknowledge, reject, crash, recover, or apply an authorized
change. Internal actions may be hidden when comparing boundary behavior. I/O automata offer a suitable
reference for composition, external actions, and implementation relationships [40]. Fairness, failure, and
clock assumptions must be specified separately from connectivity.
10 Network views, sparse algebra, and architectural analysis
The port hypergraph is the structural authority for executable connectivity. Many analyses require a
simpler derived graph, but the projection must state what it preserves and what it discards. A graph of
possible calls differs from a graph of deployments, a graph of actual invocations, and a graph of data
derivations. Combining them indiscriminately produces answers that are computationally precise but
semantically wrong.
10.1 A worked incidence example
Consider one publication with a sender port 𝑝 0 and two subscriber ports 𝑝 1 , 𝑝 2 . Let 𝑒 0 be the publication
hyperedge and let three incidence occurrences associate those ports with their roles. For the message lane,
define a tail-incidence matrix 𝑇 ∈ {0, 1} | 𝑃 | × |𝐸 | and a head-incidence matrix 𝐷 of the same shape:
1 0
𝑇 = 0 , 𝐷 = 1 . (10)
0 1
Over the Boolean semiring, 𝐴 = 𝑇 𝐷 T is the possible sender-to-receiver adjacency matrix:
0 1 1
𝐴 = 0 0 0 . (11)
0 0 0
Boolean addition means logical OR and Boolean multiplication means logical AND. Thus 𝐴𝑖 𝑗 is true
if there exists a selected hyperedge permitting the projected relationship from 𝑝 𝑖 to 𝑝 𝑗 . GraphBLAS
standardizes related sparse-algebra building blocks for graph algorithms [47].
This matrix loses edge identity, individual subscription metadata, repeated incidences, and enablement
rules. Two independent publications could yield the same 𝐴. A collective join requiring all inputs could
have the same possible-flow projection as a relationship allowing any one input to act. The matrix is
useful for possible-flow reachability, not as a replacement for the original semantics.
Do not materialize a dense |𝑃| × |𝑃| matrix for routine operation. Sparse incidence indexes can traverse
the same relationship directly. Matrix notation describes an analysis; it does not dictate storage or require
a GPU.
10.2 Reachability, strongly connected components, and domination
For a selected binary projection, reachability asks whether a path exists. Strongly connected components
identify maximal groups in which every vertex can reach every other. They are useful for detecting cycles
in dependencies or finding mutually dependent modules. A cycle is not necessarily a bug: event loops,
controllers, and conversational protocols intentionally contain feedback. A cycle violates an invariant
only in a dialect that requires acyclicity, or when its behavioral semantics make it erroneous.
A vertex 𝑑 dominates 𝑣 relative to an entry 𝑠 when every path from 𝑠 to 𝑣 passes through 𝑑. A synthetic
super-entry can collect several allowed ingress points. This supports a structural check for bypasses
around an enforcement point. However, the graph must include all relevant execution paths, and the
25
Page 26
Extracted text for page 26
Reaktor: An Extensible Software Engine Technical preprint
enforcing operation must perform the required check on the correct authenticated request and resource.
Dominance in a dependency graph is not evidence of execution dominance.
An analysis result should therefore carry both a finding and a scope claim: which entries, edge kinds,
code regions, and foreign systems were included; which transfer summaries were trusted; and where
unknown edges remain. An unmodeled reflection or native callback can prevent a universal claim even
when the visible graph has no bypass. Classical graph algorithms remain valuable without overstating
their scope [48, 46].
10.3 Hypergraph-aware enablement
Suppose a workflow step needs both a payment authorization and an inventory reservation. The condition
is conjunctive. Reaching one input does not enable the step. Let 𝑅(𝑥) be the set of required input roles for
transition 𝑥, and 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒(𝑟) the corresponding token predicate. Then
Û
𝐸𝑛𝑎𝑏𝑙𝑒𝑑 (𝑥) = 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒(𝑟) (12)
𝑟 ∈𝑅(𝑥)
expresses the relevant join condition. A competing queue instead chooses one eligible receiver for an
attempt; a publication creates obligations for each eligible subscription. These operations can share
incidence storage while requiring different interpreters.
For diagnosis, the workbench can display why a collective transition is disabled: missing reservation,
expired authorization, incompatible revision, or exhausted admission credit. A single “unreachable” color
discards the causal explanation. Protocol-specific explanation is more useful to both a developer and an
agent than a generic topology warning.
10.4 Weighted networks and cost models
Weights can represent bytes, measured latency, expected call frequency, resource cost, or a declared
engineering penalty. Their units and interpretation matter. A latency weight is not an authorization
condition. A measured average is not a worst-case bound. A path’s costs add only when the modeled
stages actually execute serially under the chosen interpretation.
For a placement 𝜋 and hyperedge 𝑒, a simple communication surrogate is
∑︁
𝐶𝑐𝑜𝑚𝑚 (𝜋) = 𝑤 𝑒 max(0, |{𝜋(𝑜(𝑏( 𝑗))) | 𝑎( 𝑗) = 𝑒}| − 1) . (13)
𝑒∈𝐸
This counts extra occupied domains and weights them by a selected estimate. It is not an exact network
bill: traffic volume, replication, routing, and compression can change the real cost. It can nevertheless
rank candidate placements when used transparently and validated against observations.
Optimization must obey hard constraints first. A low-latency plan that co-locates every replica in
one failure domain may violate availability requirements. A cheaper route may cross a forbidden trust
boundary. The result is constrained multi-objective optimization, usually solved with heuristics or
bounded optimization rather than a claim of universal optimality. The planner should report its objective,
constraints, feasible alternatives, and evidence quality.
10.5 Spectral methods: useful projections, limited meaning
For an explicitly chosen undirected weighted projection, let 𝑊 be symmetric with nonnegative weights,
𝐷 𝑊 its diagonal degree matrix, and 𝐿 = 𝐷 𝑊 − 𝑊 its Laplacian. For a real-valued assignment 𝑧 to
vertices,
1 ∑︁
𝑧 T 𝐿𝑧 = 𝑊𝑖 𝑗 (𝑧 𝑖 − 𝑧 𝑗 ) 2 . (14)
2 𝑖, 𝑗
26
Page 27
Extracted text for page 27
Reaktor: An Extensible Software Engine Technical preprint
The identity follows by expanding the square and using symmetry. It measures disagreement across
heavily weighted neighboring vertices. Spectral embeddings can therefore help suggest clusters or layouts.
The vector space here is the space of numerical vertex assignments, not the set of software systems [49].
Symmetrization can discard direction, roles, and the distinction between an AND-join and an OR-choice.
A spectral cluster may be visually coherent but unsuitable as a security, deployment, or update boundary.
Reaktor should treat spectral partitioning and embeddings as proposal generators, followed by semantic
validation.
10.6 Views are queries with obligations
A projection should specify its entity scope, selected relations, direction, time/revision context, abstraction
rules, and completeness requirements. Some views preserve identity; others aggregate several entities into
one summary. Aggregated views need a drill-down mapping so that a diagnostic or proposed mutation
can be traced back to actual entities.
The editor can collapse a service and show one aggregate edge while retaining operation-level identities
in the underlying query result. An agent can request only the state and contracts relevant to a feature.
A verifier can demand a closed-world projection of all paths to a protected effect. These uses share the
graph model but differ in their admissible omissions. A layout omission is acceptable for readability; a
verification omission must be justified.
11 Ports, contracts, and shared service interfaces
11.1 Two dimensions of an endpoint
An endpoint combines a signature with a protocol shape. Its role selects the endpoint’s perspective:
EndpointType = Signature × Protocol × Role. (15)
The signature describes exchanged schemas. The protocol describes permitted sequences, completion,
errors, cancellation, and demand. A role may be a caller, handler, producer, consumer, authority, observer,
or a named session participant. Well-formed endpoint types form the admissible subset of this product.
Role compatibility is checked against the edge profile rather than inferred from a universal input/output
arrow.
Profile Endpoint roles Required interpretation
Reference<T> Requires / provides Access to an interface with declared identity, lifetime, and locality.
Value<T> Source / sink A value dependency with evaluation and purity rules.
Call<Q,R,E> Caller / handler A finite request with a typed domain outcome and explicit
infrastructure failures.
Message<M> Sender / receiver One-way business delivery; admission acknowledgement is distinct
from completed processing.
Stream<T> Producer / consumer A sequence with ordering scope, demand, termination, and
cancellation.
State<S> Authority / observer A revisioned snapshot and a defined transition to subsequent
changes.
Session<Π> Protocol-defined A long-lived conversation following protocol Π.
Table 7: Standard profiles. Profiles share the same port and incidence representation; they are not distinct graph
storage engines.
27
Page 28
Extracted text for page 28
Reaktor: An Extensible Software Engine Technical preprint
These profiles are extensible, but an extension must declare its structural checks, behavior, adapter
requirements, and available analyses. An unknown profile may remain visible as opaque structure. It
cannot silently become executable or verified.
A value is not automatically a call returning a value. That lowering is valid only if evaluation,
purity, failures, and lifetime are preserved. Similarly, state observation is not merely a stream: snapshot
acquisition and subscription must specify whether an intervening update can be missed, which revision
the snapshot represents, and how observers recover from gaps.
11.2 Language-neutral contract identity
A contract has a stable nominal identity and an immutable revision, with request, result, error, item,
or frame schemas as appropriate. A compatibility relation is separate from both nominal identity
and semantic-version notation. Matching major versions is a release policy, not a proof of behavioral
compatibility.
The wire model specifies integer ranges, nullable versus absent values, field identifiers, unknown
variants, time representations, and encoding constraints. Runtime registries associate schema references
with Kotlin serializers, native codecs, and foreign-language bindings. An application class name, serializer
instance, HTTP path, or deployment address is not the canonical identity.
For a call, the handler must accept the requests the caller can issue, and the caller must understand
the outcomes the handler can produce. Schema variance is only one part of that condition. Changed
authorization requirements, strengthened preconditions, altered cancellation behavior, or different error
meanings can be incompatible even when the payload schema is unchanged.
11.3 Cardinality and collective operations
Binding cardinality counts a port’s logical connections. Edge arity counts incidence occurrences. Routing
cardinality counts selected recipients for one invocation. Execution cardinality limits simultaneous work.
These quantities are independent: one logical service binding can select one of many replicas while
admitting many concurrent calls.
Coordination profiles include point-to-point, anycast, broadcast, keyed routing, gather, and quorum.
Partitioning does not itself define ordering or exclusive ownership. A scatter/gather call must expose an
aggregate outcome, such as a keyed collection or a quorum result; it cannot retain an ordinary single-result
contract while discarding outcomes implicitly. A one-way message profile can require a durable-admission
receipt without claiming that its business effect has completed.
11.4 Shared API authoring
A shared service interface remains the agreement between clients, implementations, tests, and source-
navigation tools. Its members describe logical operations rather than transport-specific handler classes.
The following syntax is illustrative of the proposed API:
28
Page 29
Extracted text for page 29
Reaktor: An Extensible Software Engine Technical preprint
@GraphService("bestbuds.messaging")
interface MessagingApi {
@Operation("message.send")
val send: Call<SendMessage, ChatMessage, SendError>
@Operation("message.watch")
val watch: ServerStream<WatchMessages, MessageEvent, WatchError>
}
class MessagingServer(
graph: Graph,
private val repository: MessageRepository,
) : ServiceNode(graph), MessagingApi {
override val send by handles(MessagingApi::send) { request, context ->
repository.send(request, context)
}
override val watch by handles(MessagingApi::watch) { request, context ->
repository.watch(request, context)
}
}
class ChatInteractor(graph: Graph) : Node(graph) {
val sendMessage by api(MessagingApi::send)
}
A generated client and a test implementation implement the same interface. Abstract API classes
remain a valid alternative. A whole-service handle corresponds to a bundle of caller ports owned by the
consuming node. Member references retain source navigation and establish operation identity without
duplicating a second hand-authored registry.
Elaboration generates descriptors for the signature, protocol, caller and handler endpoints, source
locations, and optional exposure metadata. HTTP mounting, Worker bindings, local dispatch, and FFI
are realizations of the operation. The current transport-dependent ServiceEndpoint.portType and
handler-backed ServiceNode are implementation seams for this separation [9]. The service contract
layer is part of the graph architecture even when maintained in a separate package or build module.
A common interface establishes agreement within its compilation boundary. Deployed older clients
and foreign-language services still require manifest-based compatibility checks and conformance tests.
Server-side validation remains mandatory for requests received from untrusted callers.
11.5 Context, effects, and failure
Business payloads are separate from invocation context. Context contains authenticated identity,
authorization scope, tracing, deadlines, cancellation, and consistency tokens under explicit propagation
rules. Client-supplied metadata is not an authenticated principal. Local realizations retain applicable
enforcement rather than bypassing it when a network hop disappears.
Domain rejection is distinct from invalid payloads, authorization failure, unavailability, cancellation,
deadline expiry, and an unknown outcome. A timeout can leave a remote operation committed. Repeated
invocation therefore requires an explicit idempotency contract or a caller-visible possibility of repeated
effects.
A raw local reference is not automatically remotely realizable. Object identity, mutable aliases, captured
state, and lifetime can be essential to its meaning. A placement change must choose a supported proxy
contract or fail. Effects summarized by an interface remain declared assumptions until established by
implementation analysis, encapsulation, or conformance evidence.
29
Page 30
Extracted text for page 30
Reaktor: An Extensible Software Engine Technical preprint
12 Interface contracts and implementation architecture
The architecture requires a small number of stable interfaces between authoring, analysis, storage,
execution, and external providers. This section specifies those boundaries more concretely. The Kotlin
fragments are interface sketches: supporting identifiers and descriptor types are opaque versioned values,
and omitted implementations are not implied to exist. They are not a release-ready library or a claim of
compiled conformance.
12.1 Identity, revision, and schema directories
Logical identity answers which entity; a revision answers which immutable description; a runtime handle
answers which currently bound implementation. Keeping these questions separate avoids invalidating
architecture references on every process restart and prevents a local array index from becoming a permanent
external name.
An entity identifier includes or resolves within an authority namespace. A descriptor reference identifies
an immutable revision by content or registry revision. A runtime handle includes the registry/generation
necessary to interpret its slot. Boundary APIs use stable identifiers; the compiler interns them into
compact local indexes after validation.
data class DescriptorRef(
val authority: AuthorityId,
val identity: DescriptorId,
val revision: ContentHash,
)
data class EndpointTypeDescriptor(
val signature: DescriptorRef,
val protocol: DescriptorRef,
val role: RoleId,
)
interface ContractRegistry {
suspend fun resolve(ref: DescriptorRef): ContractDescriptor
suspend fun compare(
required: DescriptorRef,
offered: DescriptorRef,
environment: CompatibilityContext,
): CompatibilityResult
}
CompatibilityResult distinguishes compatible, incompatible with a counterexample, and unknown.
It can include an explicit adapter requirement. The registry must not silently identify two nominal
contracts merely because their serialized fields currently look similar. Conversely, schema-compatible
revisions can remain distinct identities for auditing and release analysis.
Wire schemas should support a portable core of products, sums, optional fields, bounded integers,
strings, byte sequences, collections, and declared domain refinements. A field’s absent value is distinct
from an explicit null when the protocol distinguishes them. Numeric units, coordinate frames, and effect
semantics are additional typed metadata or refinements, not arbitrary comments. An implementation can
use richer language types internally and lower them to this core at a boundary.
12.2 Graph readers expose snapshots, not mutable internals
A graph reader resolves entity records at one selected semantic revision. It offers indexes and cursors rather
than requiring clients to download a complete graph. Query results retain evidence and completeness
information.
30
Page 31
Extracted text for page 31
Reaktor: An Extensible Software Engine Technical preprint
interface GraphReader {
suspend fun snapshot(ref: RevisionRef): SnapshotHandle
suspend fun query(
snapshot: SnapshotHandle,
query: GraphQuery,
access: ReadAuthority,
): QueryPage
suspend fun explain(finding: FindingRef): Explanation
}
data class QueryPage(
val revision: RevisionRef,
val records: List<EntityRecord>,
val next: QueryCursor?,
val completeness: CoverageClaim,
val evidence: List<EvidenceRef>,
)
A cursor is bound to the query, revision, and access scope. Continuing it after arbitrary mutation must
either retain the referenced snapshot or return a clear stale-cursor result. A federated result can carry
several source watermarks; its envelope must not misrepresent them as a simultaneous snapshot of all
systems.
CoverageClaim is more precise than a confidence number. It can state that all declared ports in a
module were returned, that a source scanner covered specific files, or that a service map contains sampled
observations from a time interval. An agent cannot infer the absence of an unobserved dependency from
any of those claims unless the relevant closed-world condition is established.
12.3 Selectors, traversals, visitors, and passes
The graph’s extensibility depends on a concrete interpretation mechanism. The visitor design separates
four responsibilities: a selector chooses the relationships in a view; a traversal determines visit order; a
visitor produces a typed result; and a pass packages those choices with dependencies and diagnostics [28].
This separation lets routing, wiring, authorization coverage, context export, and deployment analysis
reuse the same structural substrate.
A selected arc carries its meaning: containment, incidence with a role, route attachment, data lineage,
or another declared relation. Returning only a neighboring entity would lose information needed to
interpret a port hypergraph. Traversal context identifies the current entity, incoming relation, scope path,
and source revision. A path through an exposed module boundary must not be confused with arbitrary
permission to inspect its private implementation.
interface Visitor<R> {
fun enter(context: VisitContext): VisitDecision
fun leave(context: VisitContext) {}
fun result(): R
}
interface GraphPass<R> {
val key: PassKey<R>
val dependsOn: List<PassKey<*>>
val selector: Selector
val traversal: Traversal
fun visitor(context: PassContext): Visitor<R>
}
The types above describe the semantic API. A hot traversal can operate over primitive-index cursors and
reuse context storage rather than allocate rich wrappers for every arc. DFS, BFS, post-order traversal, and
31
Page 32
Extracted text for page 32
Reaktor: An Extensible Software Engine Technical preprint
topological order have different contracts. Topological traversal requires an appropriate acyclic projection;
it is not valid merely because the containing application is called a graph.
A route-index pass can produce a RouteIndex; a deep-link planner consumes it; an auth-coverage
pass produces findings for the same route surface; an installation plan then connects permitted ingress
adapters. Similarly, wiring produces a binding report and proposed patch rather than mutating ports
during a read-only walk. A pass that installs a runtime subscription returns a lifecycle-owned installation
operation, not an untracked side effect.
Pass dependencies form a separate analysis graph. Its nodes are analyses, not application components.
Cached results identify the snapshot, descriptor versions, query dependencies, and policy scope on which
they depend. Invalidation must include predicate dependencies: adding an ingress can invalidate a finding
about all paths without modifying any previously visited entity. Reactive passes consume an explicit
event stream and close with their owner scope. Stable traversal ordering makes fixed-snapshot results
reproducible; it does not make arbitrary remote effects or concurrently observed executions deterministic.
The benefit is practical: adding a new semantic aspect need not add branches to every node class or
create another source of topology. A module contributes its vocabulary and passes, while the engine
supplies the shared indexing, lifecycle, diagnostics, and change protocol.
12.4 Graph patches are transactions over a semantic revision
A patch contains operations such as adding nodes, ports, edges and incidences; changing attributes or
descriptor references; and replacing a module region. It includes an expected base and preconditions.
Derived records are recomputed or invalidated by the owning subsystem rather than directly overwritten
by arbitrary clients.
data class PatchProposal(
val id: ProposalId,
val expectedBase: RevisionRef,
val operations: List<GraphOperation>,
val preconditions: List<PredicateRef>,
val sourceDelta: SourcePatchRef?,
val provenance: ProvenanceRef,
)
interface GraphWriter {
suspend fun prepare(
proposal: PatchProposal,
authority: ChangeAuthority,
): PreparedChange
suspend fun commit(
prepared: PreparedChangeRef,
approval: ApprovalRef,
): CommitResult
}
Preparation checks authorization, resolves immutable descriptors, constructs a candidate, validates its
structural invariants, computes impacted obligations, and produces a reviewable result. Preparation is
not a reservation of the current revision forever. Commit rechecks the expected base or revalidates the
relevant read dependencies under a sound concurrency protocol.
A minimal correctness-first implementation serializes expected-base validation and publication. More
concurrency can be introduced through optimistic validation, but it must handle predicate dependencies.
A proof that “no alternative ingress exists” depends on possible new edges, not only records that were
read. Two disjoint row updates can therefore conflict semantically. Any automatic rebase must produce a
newly validated candidate, not simply replay writes after an unnoticed base change.
32
Page 33
Extracted text for page 33
Reaktor: An Extensible Software Engine Technical preprint
Source-backed changes have an additional round trip. The authoring adapter produces a source patch;
elaboration of the edited source produces a semantic delta; the system checks that this delta matches the
approved intent within a declared equivalence. Unsupported source edits remain ordinary source changes
requiring review. The graph is not authorized to overwrite unowned source regions to force a round trip.
12.5 Protocol registries and semantic extension packages
A protocol profile describes role signatures, legal state transitions, coordination rules, cancellation,
completion, and required environmental capabilities. A realization provider states which profiles it
implements and under what conditions.
interface ProtocolModule {
val descriptor: ProtocolDescriptor
fun validate(edge: EdgeView): List<Finding>
fun obligations(edge: EdgeView): List<PropertyObligation>
fun behavior(edge: EdgeView): BehaviorModelRef?
}
interface RealizationProvider {
val descriptor: ProviderDescriptor
fun supports(request: RealizationRequest): SupportResult
suspend fun lower(request: RealizationRequest): LoweredRegion
}
A profile must not obtain execution authority by loading a validator plugin. Validators themselves are
tooling code with a trust and resource scope. Untrusted validation extensions can run in constrained
processes, and their output can be advisory unless the project explicitly adopts them into its assurance
boundary.
Standard modules can provide direct references, unary calls, request/response streams, publication,
competing work delivery, state subscriptions, actor protocols, and sessions. Less common coordination
rules remain possible through versioned modules. The kernel stores the references and preserves their
invariants; it does not acquire a branch for every broker product or UI framework.
12.6 Execution handles and invocation context
A compiled call endpoint resolves to a binding whose contract is already checked. The invocation carries
runtime context separately from its business payload. A generated client preserves the shared service
interface from Section 11; it does not require callers to manually construct graph commands for routine
execution.
data class InvocationContext(
val invocation: InvocationId,
val authenticatedSubject: SubjectRef,
val authority: InvocationAuthority,
val deadline: Deadline?,
val trace: TraceContext,
val consistency: ConsistencyRequirement?,
val executionView: ExecutionViewRef,
)
interface BoundCall<Q, R, E> {
suspend fun invoke(
request: Q,
context: InvocationContext,
): CallOutcome<R, E>
}
33
Page 34
Extracted text for page 34
Reaktor: An Extensible Software Engine Technical preprint
The trusted runtime constructs authenticated context from appropriate credentials and local authority.
A client-provided subject field is merely input until validated. CallOutcome separates domain results
from transport/infrastructure outcomes, including uncertainty about commitment. A cancellation request
is not necessarily proof that execution stopped.
The production ABI need not allocate this entire record for every local call. Generated bindings can
use an existing scope object, direct references, or compact fields. The semantic requirement is that the
relevant context is available and enforced, not that every execution passes a large generic map.
12.7 Streams and state subscriptions
A stream binding returns a scoped subscription with explicit request/cancel or another declared demand
protocol. It identifies sequence scope, gap detection, terminal outcomes, and ownership of buffered
frames. A receiver that cannot keep up can suspend admission, drop under a declared lossy profile, or fail
the subscription; these are not interchangeable behaviors.
A state subscription additionally needs a no-gap handoff from its snapshot. One valid implementation
establishes a subscription at revision 𝑣, captures the corresponding snapshot, and then delivers changes
after 𝑣 from a retained log. Another uses a transactional snapshot and cursor. Both must define what
happens if the cursor expires during initialization.
data class StateStart<S>(
val snapshot: S,
val revision: StateRevision,
val changes: ChangeSubscription,
)
interface StateEndpoint<S> {
suspend fun start(
request: StateObservationRequest,
context: InvocationContext,
): StateStart<S>
}
The returned state is an immutable value or controlled view, not a reference that lets an observer mutate
the authority’s internal object. A merged replicated state may use a causal frontier rather than one scalar
revision. The chosen profile defines the revision algebra.
12.8 Lifecycle ownership
A runtime component progresses through preparation, binding, activation, draining, stopping, and
retirement according to its profile. Lifecycle hooks have different permissions. A prepared candidate may
resolve contracts and allocate resources without accepting production traffic. An active component may
create timers and subscriptions within its owner scope. Draining prevents new admission but does not
automatically cancel work whose contract requires completion.
Closing a scope cancels or transfers its owned resources according to policy. A callback to a retired
generation must be rejected or dispatched to a still-pinned valid generation. These obligations apply to
native objects, Hermes functions, file handles, database subscriptions, and UI event handlers alike. A
common lifecycle vocabulary is useful; a single universal cleanup implementation is not.
12.9 Compilation outputs and diagnostics
Compilation should return a coherent plan and source-linked findings, not only generated files. A lowered
region maps each relevant logical entity to implementation bindings, artifacts, codecs, and resources. It
34
Page 35
Extracted text for page 35
Reaktor: An Extensible Software Engine Technical preprint
records the rule and version used to lower the region so that later evidence can be invalidated when that
rule changes.
A failed lowering can report that an operation requires lossless delivery but the selected adapter only
supports a lossy profile, or that a borrowed native buffer cannot cross an asynchronous boundary. An
ambiguous service binding should identify the competing providers. Such findings are useful even when
no formal verifier is enabled.
The central interface discipline is stable meaning with replaceable representation. Public application
APIs remain small. The descriptor and provider interfaces carry the richer contracts required by compilers,
tools, and proofs. The runtime specializes them into the narrow mechanisms needed at each execution
boundary.
13 Hyperedges, modules, and graph rewriting
13.1 Native hyperedges and reified components
Native hyperedges represent multi-party relationships directly. Their identity can carry policies, prove-
nance, deployment mappings, and observations. Incidence metadata can represent distinct subscription
filters, participant positions, or per-membership requirements.
Representational reification, as in Proposition 9.2, is a storage or analysis encoding. Semantic reification
introduces an actual component. A queue with durable state, administration ports, lifecycle, and an
independently meaningful identity can be a node in the logical model. A publication relationship can
remain a hyperedge even when its physical realization contains broker topics and subscriptions. These
representations describe different abstractions rather than competing truths.
Í
Let 𝐾 = 𝑥 ∈𝐸 |𝐽 𝑥 |. Native edge records plus incidence records require 𝑂 (|𝐸 | + 𝐾) connectivity
storage. An incidence/star encoding also requires linear storage. Neither representation is inherently
faster; compact versions can compile to the same arrays. A directed clique expansion can instead
Í
require 𝑂 ( 𝑥 |𝑇𝑥 ||𝐻 𝑥 |) pairwise arcs and discard collective identity. It is a derived view, not the default
representation. Delivering an event to 𝑘 receivers still requires the corresponding physical delivery work.
13.2 Declarative graph patches
A patch is a revision-relative value containing operations, preconditions, and provenance. Structural
operations add or remove nodes, ports, edges, incidences, attributes, and semantic relations. A patch may
also modify exposed interfaces, provided all affected boundary obligations are checked. Constructors do
not publish architectural mutations as incidental side effects.
Patch admission checks permissions separately from validity. The resulting candidate graph is validated
against the current authority revision. Events are emitted after successful publication. A failed validation
leaves the previous revision intact. Runtime preparation must not perform irreversible external effects
before the corresponding operation plan has been authorized.
Algebraic graph transformation supplies a vocabulary for matches, preserved interfaces, application
conditions, and dangling references [50]. Reaktor patches can be encoded as typed incidence-graph
rewrites. This does not establish confluence or behavioral preservation for arbitrary patch sequences;
those are separate properties.
Lemma 13.1 (Structural patch safety). Assume an initial graph satisfies Valid𝑠 . Suppose every commit
checks its expected base revision, validates the entire candidate against that revision, and publishes the
candidate at one serialized commit point. Rejected candidates do not mutate the published graph. Then
every published graph satisfies Valid𝑠 .
Proof. The initial revision is valid by assumption. For an accepted next revision, the serialized base check
prevents publication of a candidate validated against a different head. Candidate validation establishes
35
Page 36
Extracted text for page 36
Reaktor: An Extensible Software Engine Technical preprint
Valid𝑠 before publication. Rejection preserves the induction hypothesis. Induction over successful
commits proves the claim. □
The lemma specifies an implementation obligation. It does not prove that a particular validator is sound,
that a storage implementation commits atomically, or that external deployments are transactional.
13.3 Concurrent editing
Concurrent proposals carry source and semantic read sets, write sets, and expected revisions. Disjoint
entity writes may still conflict through global constraints, such as uniqueness or the absence of a forbidden
path. A merged proposal is revalidated. For scalable editing, independent scopes may commit separately
when their composition rules justify that independence.
Conflict-free replication of editor state can support convergence of suitable data, but convergence alone
does not preserve arbitrary architectural invariants. Invariant-confluence analysis provides a relevant
criterion for identifying operations that can avoid coordination under stated merge semantics [39]. Security
policy, ownership transfer, and protected release publication use explicitly coordinated authority where
required.
14 Computational semantics and flow-based programming
A graph is a representation of relationships. A program additionally defines how state changes, how
values are produced, when operations are enabled, and which effects become visible. Turing completeness
is a property of that executable interpretation, not of drawing nodes and arrows. Reaktor should support
several computational dialects over the same structural substrate rather than make every connection obey
one universal scheduling rule.
14.1 A hierarchy of executable dialects
The simplest dialect contains pure expressions and value dependencies. An expression can run once
its arguments are available. When the dependency graph is acyclic, a topological ordering provides
an evaluation order. Independent pure expressions can be reordered without altering a result under
the specified numerical semantics. Floating-point reassociation, exception behavior, and observable
resource use require separate care; mathematical equality over real numbers is not automatically equality
of machine computations.
An effectful dialect adds explicit sequencing, branches, loops, resource acquisition, and cancellation. A
stateful dialect introduces owned state and message handling. A durable dialect adds persisted decisions,
checkpoints, retryable activities, and recovery. A real-time dialect adds timing, resource, and scheduling
constraints. Each dialect declares which analyses and transformations are valid. A dataflow fusion
pass should not cross an externally observable transaction boundary merely because two operations are
adjacent.
MLIR provides an industrial precedent for extensible intermediate representations and progressive
lowering across abstraction levels [51]. Reaktor’s analogous requirement is a shared structural substrate
with domain-specific semantics, not adoption of a single compiler IR as the full application knowledge
graph. Source code and the semantic graph need traceable mappings in both directions, while unsupported
arbitrary source round-tripping remains outside the guarantee.
14.2 Kahn networks and deterministic streams
Kahn’s model describes deterministic processes connected by conceptually unbounded FIFO channels.
Blocking reads and the absence of scheduling-dependent observations permit a denotational account in
36
Page 37
Extracted text for page 37
Reaktor: An Extensible Software Engine Technical preprint
terms of stream transformations and least fixed points. Formalizations connect this model to complete
partial orders and machine-checked reasoning [29, 30].
The important lesson for Reaktor is that attractive properties arise from restrictions. A process that
observes whether a queue is currently empty and chooses a different output can expose scheduler timing.
A bounded implementation can block on a write where the unbounded model does not. Consequently,
compiling a deterministic network to bounded channels requires a separate argument about buffer sizes,
scheduling, or admissible deadlock behavior.
Consider two processes that each attempt to send two items before receiving two. With unbounded
channels both can finish their sends. With capacity one in each direction, both may block on their second
send. Payload types and structural connectivity are unchanged, but progress differs. A lowering must not
claim to preserve the unbounded semantics without addressing this case.
A practical stream profile should therefore declare whether production is push- or demand-driven,
whether buffering is bounded, what happens on overflow, and which termination events are visible.
Determinism is an optional qualified property of a profile and its implementations. It is not a default
consequence of Stream<T>.
14.3 Synchronous dataflow and balance equations
Synchronous dataflow (SDF) restricts actors to fixed token production and consumption rates, enabling
static scheduling analyses for appropriate signal-processing networks [52, 53]. Let a channel from actor
𝐴 to actor 𝐵 produce 𝑝 tokens per firing of 𝐴 and consume 𝑐 tokens per firing of 𝐵. A periodic balanced
schedule requires
𝑝𝑞 𝐴 = 𝑐𝑞 𝐵 , (16)
where 𝑞 𝐴, 𝑞 𝐵 count actor firings per period. For 𝑝 = 2 and 𝑐 = 3, the smallest positive integer balance is
𝑞 𝐴 = 3, 𝑞 𝐵 = 2. Across a network these constraints form Γ𝑞 = 0 for a topology/rate matrix Γ.
This is a genuine use of linear algebra: a null-space calculation describes necessary token balance.
A positive solution alone does not establish a valid bounded schedule. Initial tokens, cycles, firing
enablement, and buffer capacity still matter. Two actors in a cycle with no initial token can satisfy balance
while neither can start.
Reaktor can expose an SDF dialect for media, sensor processing, or other fixed-rate pipelines. The
compiler may compute repetition vectors, construct schedules, and allocate bounded buffers under that
dialect’s assumptions. A general web service, whose output count depends on data and remote responses,
should not be forced into the same model. It can be connected through an explicit boundary that states the
relevant rate or buffering contract.
14.4 Petri nets and resource accounting
A Petri net describes places containing tokens and transitions that consume and produce them. It is useful
for reasoning about resource availability and synchronization. In an ordinary net, a transition 𝑡 is enabled
only when every input place has enough tokens. If 𝑀 is the marking and 𝐶 the signed token-incidence
matrix, a firing changes the marking to 𝑀 ′ = 𝑀 + 𝐶·𝑡 . A vector 𝑦 with 𝑦 T 𝐶 = 0 defines a conserved
token sum 𝑦 T 𝑀 [54].
A bounded work queue offers a simple Reaktor interpretation. A capacity pool contains 𝐾 credits.
Admitting work moves one credit to the set of outstanding jobs; terminal completion returns it. The
invariant is
𝐶𝑟𝑒𝑑𝑖𝑡𝑠 + 𝑂𝑢𝑡𝑠𝑡𝑎𝑛𝑑𝑖𝑛𝑔 = 𝐾, 𝐶𝑟𝑒𝑑𝑖𝑡𝑠 ≥ 0. (17)
The token model makes a common bug visible: returning a credit both on timeout and on a later completion
can over-admit work. The implementation needs a unique terminal transition or idempotent credit return
keyed by the work identity. A client timeout is not necessarily that terminal transition.
37
Page 38
Extracted text for page 38
Reaktor: An Extensible Software Engine Technical preprint
This does not require every Reaktor application to be authored as a Petri net. A protocol module can
export a Petri-net or transition-system interpretation for analysis while presenting an ordinary Kotlin API.
Structural hyperedges describe participation; the interpreted transitions explain enablement and resource
movement.
14.5 An explicit Turing-complete behavior dialect
A general-purpose behavior dialect can contain a finite controller, conditionals, mutable storage, and an
unbounded conceptual tape. One step reads the tape symbol at the current position, selects a transition
from a finite table, writes a symbol, changes the position by one, and updates the controller state. Represent
the read, branch, write, and state-update operations as typed nodes with explicit control and value edges.
A feedback edge enables the next step unless a halting state is reached.
Proposition 14.1 (Computational universality of the general behavior dialect). If the dialect implements
the operations above with unbounded conceptual tape storage and faithfully executes each transition, then
it can simulate every deterministic Turing machine.
Proof. Encode the machine’s finite transition table in the controller and its tape as the dialect’s indexed
store. The initial controller, tape, and head position encode the initial machine configuration. By
construction, one graph iteration produces the encoding of exactly the next machine configuration.
Induction on the number of iterations establishes the simulation. The graph halts precisely when the
simulated machine reaches its halting state. □
The proposition follows the standard machine model of computability [55]. It is a statement about the
proposed semantics, not a claim that the current visual editor implements this interpreter. A deployed
process has finite storage and execution time; computational universality is an idealized expressivity
result, not a promise of unlimited resources.
A less elaborate implementation can compile equivalent loops and mutable state into Kotlin or another
target language. The significance is unchanged: the semantics, not the visual notation, provide universality.
A directed acyclic graph whose nodes perform fixed finite operations once does not obtain the same
property merely by being large.
14.6 Why general verification cannot be completely automatic
Suppose a verifier could always decide whether an arbitrary program in this general dialect eventually
completes. Applying it to the simulation above would decide whether an arbitrary Turing machine halts.
The general decision procedure therefore cannot exist. This does not prevent proving termination for
particular programs, enforcing a restricted terminating dialect, or analyzing a bounded abstraction.
The engineering response is a hierarchy. Pure acyclic computations admit straightforward scheduling
checks. Restricted protocols admit finite-state exploration. Resource contracts can bound loops and
queues. General code can supply specifications, proofs, tests, or conservative summaries. Unknown
outcomes remain explicit. Expressivity and automatic decidability are design choices with a real tradeoff,
not an objection to using formal methods.
For an agent-generated transformation, the verifier should identify which class of obligation is being
asked. Type compatibility may be decidable and cheap. Termination of a bounded loop may be statically
checked. Preservation of an arbitrary external business effect may require a human-supplied specification
or domain proof. The tool should not turn an undecidable question into an unqualified success because a
test suite happened to terminate.
38
Page 39
Extracted text for page 39
Reaktor: An Extensible Software Engine Technical preprint
14.7 Multiple meanings of time
A UI animation frame, a stream element’s event time, a message-delivery attempt, a workflow checkpoint,
and a control-system sample do not share one universal clock. A dialect should distinguish logical step
order from wall-clock deadlines and from timestamps carried in data. An event-time window may need
late-arrival handling; a deadline may require a monotonic local clock; a distributed timestamp may carry
uncertainty.
A simulation can virtualize time and external effects so that a failure trace is replayable. An actual
deployment may remain nondeterministic. The mapping between simulated and real execution must state
which events, ordering constraints, and timing bounds are covered. A repeatable simulation is valuable
evidence, not proof that every real-world schedule was tested.
15 Distributed algorithms behind the execution model
The logical graph states which components can interact. A distributed realization must additionally
specify how progress, failure detection, ordering, consistency, and recovery work. Location-independent
interfaces are useful only when their contracts remain honest about these differences.
15.1 Failure models are part of the contract
A crash-stop process halts and does not recover. A crash-recovery process can restart with some durable
state and lose volatile state. An omission failure loses a message or response. A Byzantine participant
may deviate arbitrarily from its protocol. A slow or partitioned process can be indistinguishable from a
failed one to another process that has not received a response.
A realization profile should name the failures it addresses. A durable queue can recover accepted
messages after a worker crash without tolerating a malicious broker or corrupted storage. A signed artifact
authenticates an update without ensuring its code is correct. A trusted in-process reference can be suitable
within one application yet inappropriate across an untrusted plugin boundary. Broad phrases such as
“fault tolerant” should be replaced by the relevant failure model and preserved properties [40].
15.2 Causality and clocks
Lamport’s happens-before relation orders events connected by local program order and message trans-
mission, together with their transitive consequences [56]. Events not related by it may be concurrent.
Logical clocks can respect this relation without revealing all concurrency. Physical timestamps can assist
diagnosis but require clock assumptions before they can establish event ordering.
A graph observation should retain the difference between observed at, occurred at according to the
producer, and causally depends on. A query that joins traces, a database commit, and a deployment event
solely by timestamp can invent an order that the evidence does not establish.
Spanner’s use of explicitly bounded clock uncertainty is an instructive precedent for making timing
assumptions visible in a consistency protocol [57]. It does not imply that a commodity mobile device, a
JVM process, or a robot sensor supplies the same clock guarantees. A Reaktor clock capability must
describe the available service and uncertainty rather than expose one undifferentiated now() operation to
every timing analysis.
15.3 Safety, liveness, and impossibility boundaries
Safety excludes bad outcomes; liveness requires eventual progress. A consensus service may preserve
agreement during a partition by declining to complete some operations. The FLP result rules out
guaranteed termination for deterministic consensus in a fully asynchronous model with a possible process
39
Page 40
Extracted text for page 40
Reaktor: An Extensible Software Engine Technical preprint
failure [58]. It does not rule out practical consensus protocols with additional timing or probabilistic
assumptions.
Partial synchrony formalizes systems in which useful timing bounds eventually hold, or hold but are
initially unknown [59]. A deployment can therefore state that a protocol preserves safety despite delay
but requires eventual communication and a sufficiently stable period for liveness. These assumptions
belong in verification evidence and operational health interpretation.
The CAP result similarly concerns the inability to combine its specified consistency and availability
conditions when communication partitions occur [60]. It should not be reduced to an unrestricted
instruction to choose any two properties. Reaktor can expose the policy for an unavailable authority:
reject, wait, queue a provisional write, or accept an explicitly weaker operation. It cannot make that policy
unnecessary.
15.4 Linearization points and external effects
Linearizability gives concurrent operations the appearance of taking effect at individual points between
invocation and response, respecting real-time precedence [61]. It is useful for a graph revision registry,
an admission counter, or a shared state object. It is not synonymous with durability, serializability of a
multi-object transaction, or instantaneous global observation.
For a local patch registry, the successful publication of the validated revision can be the linearization
point. For a database operation, the commit protocol defines the relevant durable outcome. For an external
payment request, receipt of a timeout may leave the outcome unknown. A client cannot safely turn that
uncertainty into “the payment failed” and initiate an unrelated second payment.
The end-to-end principle explains why a lower-layer delivery success is not a complete application
correctness argument [62]. A network acknowledgement can establish reception at one layer. The
application needs evidence about the business effect and its durable identity. Reaktor should preserve
both observations rather than collapse them into one success flag.
15.5 Quorums, replicas, and ownership
For 𝑛 replicas, two quorums of size greater than 𝑛/2 intersect. This follows because two disjoint subsets
of those sizes would contain more than 𝑛 members. Intersection is a useful ingredient in replicated
protocols, not a complete consensus algorithm. Terms, leader selection, log matching, committed entries,
and membership changes still require rules. Raft provides a well-documented example of those rules
around a replicated log [63].
Reaktor should normally bind to an established coordination service rather than implement a new
consensus algorithm in every application. A placement descriptor can request an authoritative revision
registry and declare its failure-domain assumptions. An adapter then identifies the concrete implementation
and the scope of its guarantees.
An actor directory requires similar precision. A stable address identifies the logical actor; an activation
identifier identifies one running generation; a fencing epoch limits which activation can commit protected
effects. A lease holder that pauses can resume after its lease has expired. Rejecting its stale epoch at the
protected resource is what prevents it from continuing as an unauthorized writer. Merely removing it
from a routing table is insufficient when it still holds another path to that resource.
15.6 Delivery identity, effect identity, and deduplication
A message, an attempt to deliver it, and the effect it requests need distinct identities. A publication
delivered to two subscriptions creates two logical consumer obligations. Deduplicating globally by
message ID could incorrectly prevent the second subscription from performing its different effect. A
suitable key often includes the subscription or business-effect scope.
40
Page 41
Extracted text for page 41
Reaktor: An Extensible Software Engine Technical preprint
Consider a transactional consumer with key (𝑔, 𝑚), where 𝑔 is the effect scope and 𝑚 the message
identity. The consumer transaction checks for a committed receipt, applies the business update if no
receipt exists, writes the receipt, and commits both together. A uniqueness constraint prevents two
concurrent transactions from committing two receipts for the same key.
Proposition 15.1 (Scoped transactional effect uniqueness). Assume the deduplication record and protected
effect are committed atomically in a store that enforces the key’s uniqueness and the required transaction
semantics. Assume every execution of the protected effect uses this transaction, and the receipt is retained
for every permitted replay. Then at most one committed execution of the protected effect exists for each
key (𝑔, 𝑚).
Proof. A committed protected effect implies a committed receipt in the same transaction. Two committed
executions would imply two successful receipt insertions for the same unique key, contradicting the store’s
uniqueness semantics. Retries that observe the receipt return its result rather than execute the effect
again. □
The proposition does not cover an external effect performed outside the transaction. It also fails if
receipts expire before a valid replay or if an administrator bypasses the protected path. Those conditions
should be part of the profile, retention policy, and test corpus.
The outbox pattern extends the same atomicity boundary to a record of an event that must subsequently
be published. The relay may publish more than once, so subscribers still need an appropriate replay policy.
This is deliberate composition of narrower guarantees, not universal exactly-once execution.
15.7 Backpressure and overload
Backpressure communicates that a downstream stage cannot currently accept more work. Its effectiveness
depends on where buffering occurs. Suspending one coroutine does not bound memory if upstream
requests are still accepted into another unbounded queue. An end-to-end admission policy needs a budget
across relevant buffers, requests, and retained payloads.
A credit protocol can enforce a hard count bound under atomic accounting. If each admitted job
consumes one of 𝐾 credits and exactly one terminal transition returns it, then 𝑂𝑢𝑡𝑠𝑡𝑎𝑛𝑑𝑖𝑛𝑔 ≤ 𝐾.
Byte-based budgets may be more appropriate when payload sizes vary. Flow control should also address
fairness: one tenant or session must not monopolize all capacity indefinitely.
Retry is an additional arrival process. Under widespread failure, immediate retries can increase load on
the very component that cannot make progress. A profile should declare retry budget, backoff, deadline,
and terminal handling. Retry behavior can be analyzed and simulated without claiming that a particular
backoff schedule proves recovery from permanent failure.
15.8 Consistency belongs to an operation or datum
A system rarely has one useful global consistency label. A message commit may need transactional
authority; presence can tolerate stale observations; a draft can merge offline edits; a deployment registry
may require linearizable revision publication. The graph should attach requirements to these specific
objects and operations.
For a projected datum, a read-your-writes token must identify a relevant committed position and a
replica must establish that it has applied the corresponding changes before serving the dependent read.
Comparing unrelated clocks or revision counters does not establish this. For a multi-store query, one
scalar token may be insufficient; the query can require a frontier of applied positions or explicitly accept a
mixed-freshness result.
Conflict-free replicated data types provide convergence under their particular update and merge
conditions [64]. They do not automatically preserve arbitrary global business invariants. An offline draft
41
Page 42
Extracted text for page 42
Reaktor: An Extensible Software Engine Technical preprint
and a scarce inventory reservation therefore need different contracts even when both appear as mutable
values in an application.
16 Platform integration, lifecycle, and adaptive capabilities
16.1 Core as the composition-root boundary
The existing reaktor-core supplies typed Feature slots, platform Adapter objects, closable resource
primitives, and cross-platform time, dispatch, logging, atomic, and serialization utilities. Its Capability
resource marker is not an authorization token. Graph behavioral mixins and the proposed environment-
capability runtime are further distinct uses of the word [21, 65].
A platform bootstrap installs adapters at an explicit composition root. A proposed scoped runtime
directory resolves them into the dependencies a graph instance needs. Feature logic should receive those
dependencies through constructors or ports, rather than reading mutable process-global slots throughout its
implementation. This retains the existing adapter model while addressing interference between application
previews, tests, and multiple graph sessions.
The first validation pass checks required registrations and target compatibility before activation. Missing
camera support is then a startup finding or a declared fallback, not an exception discovered only after
a user presses the capture button. A weak platform-controller reference prevents accidental ownership,
but cannot guarantee that the controller remains available. Adapter outcomes must account for host
disappearance and cancellation.
16.2 Host lifecycle and graph lifecycle
A node can remain attached while an application is backgrounded. A Worker request can finish while
its isolate remains resident. An actor can be idle while its process stays healthy. The lifecycle design
therefore separates host events from graph attach, binding, activation, draining, and retirement [66].
Host adapters normalize useful signals: foreground/background, visibility, memory pressure, request
entry, scheduler invocation, and orderly shutdown where available. Each event carries its source, target,
reason, and revision context. It must not manufacture a guaranteed shutdown event on platforms that can
terminate abruptly. close() and scoped cancellation describe orderly resource release; crash recovery
requires persisted state and a restart protocol, not an assumption that cleanup always ran.
Graph lifecycle controls admission and ownership. Prepared objects may resolve descriptors and
reserve permitted local resources. Active objects may receive work. Draining objects stop new admission
according to their protocol. Retirement removes bindings only after lifetime obligations are satisfied. The
same distinction supports previews, actor replacement, UI subtrees, and LiveUpdate without forcing them
into an identical implementation.
16.3 Capabilities describe conditions, not permission alone
The proposed capability runtime normalizes device, network, renderer, storage, power, thermal, and
permission observations into profiles. A feature requests a capability at a required and preferred tier;
policy selects a strategy and records why [65]. An upload can proceed immediately, use a smaller
permitted representation, wait for suitable connectivity, or become unavailable. A denied permission does
not authorize a silent policy bypass.
Conceptually,
𝐷𝑒𝑐𝑖𝑠𝑖𝑜𝑛 = 𝑆𝑒𝑙𝑒𝑐𝑡 (𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑚𝑒𝑛𝑡, 𝐸𝑛𝑣𝑖𝑟𝑜𝑛𝑚𝑒𝑛𝑡, 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒𝐼𝑚 𝑝𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛𝑠, 𝑃𝑜𝑙𝑖𝑐𝑦).
The result includes the selected strategy, achieved tier, unmet preferences, evidence freshness, and decision
trace. Unknown measurements remain unknown. Coarse normalized classes avoid coupling product
42
Page 43
Extracted text for page 43
Reaktor: An Extensible Software Engine Technical preprint
behavior to device-model strings or unnecessary fingerprints. Adaptation policy can include hysteresis
and minimum dwell times so a noisy measurement does not repeatedly tear down a session.
Static deployment eligibility and dynamic quality are related but different. A host may provide a camera
contract while current permission makes it unavailable. A supported GPU renderer may be temporarily
unsuitable under thermal pressure. Hard safety requirements cannot be weakened by a quality fallback;
the valid response may be to stop an operation or enter a safe mode. Synthetic environment snapshots
make these decisions reproducible in tests and visible in the workbench.
16.4 Application structure at a readable level
The BestBuds refactor design gives the runtime vocabulary a practical authoring discipline: services own
boundary contracts; repositories own data access; interactors expose product data and actions; actors own
focused concurrent loops; screens render state and forward actions; design components own reusable
presentation [67]. This is not a requirement to introduce all six objects for a trivial screen. Extraction is
justified by ownership, independent testing, or a stable abstraction, not by a target file count.
The graph refinement proposal supplies corresponding ergonomic goals: declarative route bindings,
derived state, lifecycle-bound effects, exposed module interfaces, and focused state helpers [68]. Their
implementations must retain the graph identities and ownership rules. A concise DSL is useful only if an
unfamiliar engineer can still locate the underlying behavior and understand which scope cancels it.
17 Behavior and distributed execution
17.1 Wiring is not scheduling
A structural connection states that communication or dependency is available. It does not imply that every
connected node executes automatically. Reaktor separates structural wiring from behavior dialects: pure
expression graphs, event-driven control flow, actor transitions, and durable workflows. A behavior dialect
defines activation, sequencing, branching, loops, state access, and completion.
The authoring frontends elaborate supported declarative code or visual syntax into a typed behavior
IR. Arbitrary implementation bodies remain source code behind declared interfaces. Only the supported
subset has a round-trip contract between visual and textual forms. A source location or an opaque function
body must not be presented as a fully understood executable graph.
Pure subgraphs can admit optimization under their declared semantics. Effectful subgraphs require
explicit sequencing or concurrency rules. A stateful feedback loop is distinct from an accidental
combinational cycle. A join, barrier, or quorum operator contributes behavioral rules in addition to its
hyperedge topology.
17.2 Actor behavior and exclusive state
An actor profile combines a stable logical address, a mailbox protocol, state ownership, lifecycle, and
supervision rules. Its contract specifies ordering scope, reentrancy, admission behavior, cancellation, and
how failures affect accepted work. Serial mailbox handling does not imply that every coroutine launched
by the implementation is isolated from its state.
An implementation can perform background work and post results back to its mailbox. Results carry
the appropriate activation or state revision when stale completion would be unsafe. Mutable actor-owned
state is accessed through the actor’s declared transition mechanism. Escaping raw references weakens
that discipline and must be reflected in the assurance record.
Distributed activation adds an ownership protocol. Routing an address to a host is not proof that only
one activation can commit protected effects. A fencing epoch can identify the current authority, but it
is effective only when the protected resource checks it at the relevant commit boundary. Duplicate or
43
Page 44
Extracted text for page 44
Reaktor: An Extensible Software Engine Technical preprint
stale activations may exist transiently; the safety requirement concerns their permitted effects. Where a
provider supplies stronger single-instance semantics, the realization records that provider contract rather
than inferring it from an ordering key.
Supervision defines restart, resume, stop, and escalation policies. Recoverable state has a versioned
representation. An actor address includes the required application, tenant, and identity scope; a display
name alone is insufficient as a storage or security namespace.
17.3 Publication and competing delivery
A logical publication targets subscriptions, not every transient worker instance. Each subscription has
an independent identity and can define filtering, retention, retry, ordering, dead-letter handling, and a
competing consumer group. A publication profile determines which subscription set applies to an event:
membership can be evaluated at admission, at delivery, or through an explicitly versioned policy.
A durable queue profile separates enqueue acceptance, durable admission, delivery attempt, processing,
and acknowledgement. An acknowledgement of admission is not an acknowledgement of the business
effect. Delivery identities include the logical subscription or effect scope. Redelivery to one subscription
must not be mistaken for a duplicate intended effect in a different subscription.
Ordering is scoped by key, partition, or stream, and must specify what happens during retries and
ownership changes. Keyed routing alone does not establish FIFO order. Backpressure distinguishes local
demand from broker admission, buffering limits, expiry, and overload rejection. A slow consumer cannot
be hidden by an unbounded buffer in a supposedly bounded realization.
For database-backed effects, a useful profile commits a deduplication record, business mutation, and
outbox record in one database transaction. The outbox relay can retry publication. Downstream consumers
still require their own deduplication scope. Effects in unrelated databases or external APIs need a separate
transaction, idempotency, or compensation protocol. Universal exactly-once execution is not assumed.
17.4 Streams, state, sessions, and mesh
A stream contract specifies item order, loss or conflation policy, demand, buffer limits, cancellation, and
termination. A session contract additionally specifies legal conversation states and participant roles.
A transport connection can realize a session, but network reconnection is not automatically session
continuation.
State observation exposes a snapshot revision and a subscription position. An adapter must establish
a consistent handoff or return an explicit gap requiring resynchronization. Replicated state can expose
a freshness or causal requirement; “connected” does not mean “current.” Multiwriter state requires a
declared merge or agreement protocol rather than several endpoints all claiming exclusive authority.
Mesh components such as peers, rooms, tracks, relays, and session resources remain graph-visible
domain entities. Control, signaling, media, and durable event delivery can use different edge profiles. A
relay’s physical topology and an application’s logical room membership are related by realization maps,
not collapsed into one untyped connection.
17.5 Durable workflows
A workflow definition is distinct from a workflow instance, an activity attempt, and its committed outcome.
Durable execution persists sufficient history or state to recover according to the workflow’s semantics.
Recovery does not imply that an external effect was executed only once.
Workflow definitions and activity contracts are versioned. An in-progress workflow either remains
bound to compatible code, resumes through a declared migration, or stops at a documented boundary. A
code update must not reinterpret old durable history under an incompatible definition. Compensation is a
further business operation with its own failure modes, not an inverse that erases all prior consequences.
44
Page 45
Extracted text for page 45
Reaktor: An Extensible Software Engine Technical preprint
17.6 Placement and realization
Let 𝑉 denote runtime instances, 𝑁 logical nodes, and 𝐷 execution domains. The maps
realizes : 𝑉 → 𝑁, placedOn : 𝑉 → 𝐷 (18)
separate logical identity from replication and placement. Domain descriptors distinguish runtime, host,
region, failure domain, and trust boundary. These fields are orthogonal; a domain is not simply a value
from an enum mixing a language with a network distance.
A realization 𝜌 maps logical nodes and edges to physical components and communication subgraphs.
A request/reply edge may lower to a direct handler, an HTTP path, a service binding, or an FFI plan. A
publication hyperedge may lower to an outbox, topic, subscriptions, and worker groups. Replica selection
makes this a subgraph or plan rather than one permanently fixed path.
Deployment cuts are derived from placement and realization requirements. A same-process connection
can still cross a trust or ownership boundary. A remote connection requires compatible codecs, context
propagation, failure behavior, and policy enforcement. If the target cannot realize the declared semantics,
the planner rejects the placement or requires an explicit contract change.
Shared-interface placement separation has a precedent in Service Weaver [69]. Hydro makes
computation locations and communication explicit in the programming model [70]. Reaktor uses a
logical/physical separation while retaining the requirements that determine whether a proposed lowering
is admissible.
17.7 Local projections and fleet rollout
Each runtime receives its local executable subgraph and typed boundary stubs. Dynamic membership can
be represented by logical groups and provider-managed directories instead of replicating every physical
participant into every client. A workbench can expand those groups through observation queries.
A release records a compatible set of graph, artifact, schema, and policy revisions. A fleet rollout is a
distributed protocol: components can run different releases during transition. Expand–migrate–contract
sequences retain supported old contracts until their dependents have moved. Committing an authoring
revision does not establish an atomic deployment across phones, browsers, Workers, servers, and databases.
18 The system knowledge graph and data layer
18.1 Connections, relations, and facets
The executable port graph is embedded in a wider typed system model. Three constructs remain distinct.
A connection is a binary edge or hyperedge between ports, with executable semantics. A relation is a
typed assertion between system entities. A facet is local typed metadata. An authorization policy can
protect an operation through a relation without inventing artificial executable ports for policy knowledge.
Let 𝑈 be the identity universe containing structural entities and domain entities. An aspect 𝐴𝑖 =
(𝑈𝑖 , 𝑅𝑖 , 𝐹𝑖 ) selects or introduces entities, typed relations, and attributes, with explicit references into 𝑈.
Auth, navigation, data lineage, deployment, and telemetry aspects can have different node sets. They
share identities where they refer to the same entity.
Aspects have different meanings. Normative aspects impose requirements. Observational aspects
report evidence. Descriptive aspects connect source, ownership, and documentation. Domain aspects
describe their own topology. Visibility in a projection does not control enforcement: hiding authorization
annotations cannot disable an authorization requirement.
45
Page 46
Extracted text for page 46
Reaktor: An Extensible Software Engine Technical preprint
18.2 Assertions, provenance, and completeness
An assertion records its subject, relation or field, object or value, source, source revision, extraction
method, authority, valid scope, and freshness information. Evidence classes distinguish declarations,
generated facts, static inference, runtime observations, and heuristics. A confidence score is not a
permission and is not a calibrated probability unless a separate calibration procedure establishes that
interpretation.
Provider fragments are merged through declared identity and authority rules. Contradictory claims
remain inspectable. A resource can be desired but unobserved, observed but undeclared, divergent, stale,
or of unknown status. An absent observation is not proof of nonexistence when the provider query was
incomplete or failed.
A projection records its scope, filters, exclusions, assumptions, and completeness class. In an imported
system, an unobserved call can still exist. Closed-world analyses require a complete boundary or a
conservative overapproximation; otherwise the appropriate result is unknown or a scoped finding. The
phrase “complete application graph” means coverage relative to explicit boundaries and evidence, not
omniscience about arbitrary code.
18.3 Three connected data representations
The system distinguishes a data-topology graph, a product-data graph, and an observation graph. The
first contains stores, datasets, schemas, queries, authorities, projections, caches, synchronization, and
retention. The second contains application records and relationships, such as people, conversations, or
learning concepts. The third contains query executions, projection runs, checkpoints, lag, and failures.
A DataDescriptor declares the data contract, authority model, placement constraints, derived
projections, synchronization protocol, merge policy, and retention. A source dataset can be authoritative
while an on-device mirror, graph projection, and analytical view are derived. The graph records which
operations read or write the dataset and which transformations produce each copy. This extends the
authority/projection discipline in the Reaktor data-layer design [71, 8].
An authority is a logical consistency rule, not necessarily one physical machine. The default can
be server-authoritative product state. Selected collaborative fields can use a declared replicated merge
algebra. Combining those approaches requires explicit field or aggregate boundaries; a cache cannot
silently become a second authority.
18.4 A concrete data realization
The reference stack gives these abstract roles concrete implementations. The documented local store is an
ObjectDatabase/ObjectStore over SQLDelight, with SQLite-based native/JVM realizations and a
browser persistence path. Postgres supplies transactional product authority; Worker-side access uses a
Hyperdrive-backed adapter, while the JVM uses its database adapter. Memgraph supplies a relationship
projection, ClickHouse supplies analytical processing, and R2 supplies object storage. The documentation
reports the local and several server adapters separately from the proposed unifying DataDescriptor
and synchronization engine [71]. These choices define a reference profile, not a requirement that every
application deploy every store.
In the photograph example, the local draft has an installation-scoped identity and a pending upload
operation. The authoritative message record refers to an accepted media object; the object store contains
the bytes, not the authorization decision. A publication can update a conversation projection, a notification
workflow, and an analytical aggregate. Their checkpoints explain which authoritative facts they have
processed. A missing thumbnail and a stale engagement aggregate are different failures, even when both
ultimately concern the same message.
A descriptor needs to distinguish payload residence from metadata authority. Declaring that a message
is authoritative in Postgres does not imply its image bytes are also stored there. Likewise, a Memgraph
46
Page 47
Extracted text for page 47
Reaktor: An Extensible Software Engine Technical preprint
relationship can be authoritative for a deliberately graph-native domain rather than always being a
projection. The owning application declares that choice per dataset or aggregate; a technology name
cannot determine it.
// Proposed descriptor: physical names are bindings, not secrets.
val messages = dataset<Message>("conversation.messages") {
authority(transactionalStore("product"))
localMirror("conversation-working-set", scope = Installation)
objectReferences(mediaStore("attachments"))
projection("conversation-relationships", checkpointed = true)
projection("engagement-analytics", checkpointed = true)
retention(productRetentionPolicy)
}
This declaration describes intended relationships. An adapter must still implement filtered synchro-
nization, authorization, retention, and checkpoint reporting before the corresponding capabilities are
available. The inspector shows pending local intent, authoritative acknowledgment, and projection
progress separately. It does not infer successful application merely because an event was emitted.
The schema-hardening report provides a useful implementation-grounded motivation: broad com-
patibility views multiplied identity rows and amplified downstream joins, while refresh-token rotation
needed database-enforced single-use behavior [72]. A system graph can connect the query, compatibility
view, schema revision, and affected operation. Correcting the query or transaction still requires database
expertise. The benefit is making that expertise reusable through explicit projection contracts and regression
gates rather than hiding it behind a supposedly universal store API.
18.5 Synchronization and consistency evidence
Local optimistic state distinguishes pending intent from acknowledged authoritative state. Upload
operations carry stable identities and pass through server-side validation. Synchronization applies
source-origin and revision information to avoid interpreting replicated writes as fresh user intent.
Read-your-writes requires evidence that the selected replica or local mirror has applied the required
commit position or causal frontier. A timestamp, including a hybrid logical clock, is not sufficient by
itself. Cross-store queries declare whether independently fresh projections are acceptable or whether a
compatible checkpoint is required. A schema change and a projector update must preserve the relevant
checkpoint interpretation.
Lineage records connect a transformation definition to its executions and datasets. OpenLineage’s
distinction between datasets, jobs, and runs is a useful interoperability model [73]. Large product records
and telemetry remain in their appropriate stores; the system graph holds typed references and retrieves
authorized bounded slices. This prevents the architectural registry from becoming a mandatory in-memory
copy of every application datum.
18.6 Cloud resources, tools, and external systems
Cloud providers, infrastructure configuration, source indexes, build tools, tests, and operational APIs
contribute typed fragments. An operation provider exposes actions such as inspect, query, test, preview,
deploy, or drain. Its contract specifies arguments, outcomes, authorization, target scope, idempotency,
and side effects.
A tool invocation is related to its declared operation, execution attempt, logs, and artifacts. It is not
treated as successful because an agent describes it as successful. Native build receipts and operation
results remain attributable evidence. Infrastructure reconciliation compares desired state with provider
observations; it is not a direct assignment to the observed graph.
47
Page 48
Extracted text for page 48
Reaktor: An Extensible Software Engine Technical preprint
Foreign components can enter through published schemas, wrappers, source analysis, or runtime
observation. Importers must not execute arbitrary source initializers just to discover topology without
a suitable isolation and authorization model. More precise knowledge can enable more analyses, but
mutation authority still comes from an explicitly authorized operation provider, not from knowledge
fidelity alone.
18.7 Security boundaries and privacy
Reference capabilities, platform capabilities, and permissions are separate. A reference capability grants
access to a supported interface. A platform capability describes what a runtime can implement. A
permission describes what a principal may do in a context. Possessing type metadata grants none of them.
An authorization requirement is linked to its enforcement points, authenticated context, and protected
effects. Enforcement applies to local as well as remote paths. Data-dependent checks remain necessary
even when a graph proves the absence of a structural bypass. Information-flow claims require a conservative
model of internal transfers and declassification; wiring alone does not establish them.
Read access to the system graph is itself governed. Schema, lineage, traces, and source locations can
disclose sensitive information. Agent views default to the least required metadata and redacted evidence.
Secrets are references to authorized providers, not values included in snapshots. Offline access and
immediate revocation are conflicting requirements in some deployments; their chosen policy is represented
explicitly.
19 Federation, data contracts, and operational integration
The executable graph describes the portion of a system under Reaktor’s runtime semantics. The system
knowledge model connects that portion to source, data, infrastructure, release artifacts, operations, and
evidence. Federation is necessary because those facts have different owners, storage systems, lifetimes,
and access policies.
19.1 Facts have authority and provenance
An imported assertion should identify its subject, predicate, value or related entity, authority, source
revision, and observation context. Provenance can itself be a graph of entities, activities, and responsible
agents, as formalized by the W3C PROV family [74]. The existence of provenance does not establish
truth; it makes the origin and derivation of a claim inspectable.
data class SystemAssertion(
val subject: EntityRef,
val predicate: RelationTypeId,
val value: AssertionValue,
val authority: AuthorityId,
val sourceRevision: SourceRevision?,
val validContext: ContextPredicate,
val evidence: EvidenceRef,
)
interface SystemGraphProvider {
val descriptor: SourceDescriptor
suspend fun read(request: FragmentRequest): GraphFragment
suspend fun changes(after: SourceCursor): ChangePage
}
The registry does not turn competing assertions into one value through unrestricted last-write-wins. A
declaration that a queue should exist and an observation that it is absent are consistent statements about
48
Page 49
Extracted text for page 49
Reaktor: An Extensible Software Engine Technical preprint
different planes. Conflicting authorities over the same declared fact require an ownership decision or an
explicit unresolved conflict.
Identity reconciliation also needs evidence. Source symbols, deployment names, and telemetry service
names can be aliases for one component, but similar text is not enough. An importer can propose a link;
an authority can confirm it. Deletion must leave enough history to distinguish a removed resource from a
renamed or temporarily unobserved one.
19.2 Data descriptors connect topology to semantics
A dataset descriptor can name its logical schema, authority policy, representations, derivations, merge
rules, retention, and access requirements. An authority can be one server-managed transactional service
or a specifically defined replicated data type. “One authority” means one coherent rule for resolving truth,
not necessarily one physical process.
data class DataDescriptor(
val dataset: DatasetId,
val schema: DescriptorRef,
val authorityPolicy: AuthorityPolicyRef,
val representations: List<RepresentationRef>,
val derivations: List<DerivationRef>,
val merge: MergePolicyRef?,
val retention: RetentionPolicyRef,
val access: AccessPolicyRef,
)
A representation identifies whether it is authoritative, a projection, a cache, or a provisional local state.
A derivation identifies inputs, transformation code, output schema, and progress/checkpoint semantics.
An analytical projection is not permitted to become an accidental second transactional authority because
its query API also allows writes.
An applied position should be interpreted by the relevant source and projection protocol. For a single
ordered source it may be a log position. For partitioned sources it can be a vector of positions. A Reaktor
read requiring its earlier write should bind that write to the projection state actually used for the query. A
generic timestamp comparison is insufficient.
19.3 Lineage describes both definitions and runs
The definition of a transformation is distinct from a particular run. A run can fail, retry, process a
subset, or use a specific input snapshot. OpenLineage’s separation of jobs, runs, and datasets is a useful
interoperability boundary [73]. Reaktor should link those objects to operation identities and code revisions
rather than retain only a decorative edge saying “feeds analytics.”
For example, a campaign recommendation dataset depends on an engagement source, a projector artifact,
a schema revision, and a successfully applied checkpoint. An incident investigation can distinguish a dead
consumer from a running consumer that rejects a new schema. The topology explains the path; runtime
evidence explains which part of that path progressed.
Record-level product graphs remain in their stores. A social graph may contain millions of people and
relationships, while the architecture graph contains the schema, queries, services, and access paths over
that data. The workbench joins bounded authorized slices when needed. Treating every product record as
a permanently loaded architecture node would mix scale, privacy, and lifecycle concerns unnecessarily.
49
Page 50
Extracted text for page 50
Reaktor: An Extensible Software Engine Technical preprint
19.4 Builds and releases as derived relationships
A build action consumes declared source and dependency inputs and produces artifacts. Reproducibility
improves when those inputs include toolchain versions and relevant environment rather than depending on
ambient state. Bazel’s hermeticity documentation gives a practical account of isolation from undeclared
host inputs [75]; Nix provides a distinct deployment model organized around explicit derivations [76].
Reaktor need not replace either system. A build-provider interface can connect their actions and artifacts
to graph entities. A release then selects compatible artifacts, schemas, deployment plans, and update
manifests. A reproducible artifact is not automatically a safe artifact; tests and policy still determine
whether the release is acceptable.
The dependency graph used for caching must include the actual inputs to an analysis or build. If a
compiler plugin, schema registry revision, or protected policy changes, cached results depending on it
need invalidation. Negative dependencies matter as well: a query asserting that no extra implementation
exists can change when a new implementation is added.
19.5 Operational actions are typed, scoped, and evidenced
A cloud resource can expose an inspect action, a deployment preview, a controlled restart, or a query
operation. Each action specifies inputs, authority requirements, effect scope, idempotency/retry behavior,
and the form of its receipt.
interface OperationProvider {
suspend fun describe(target: EntityRef): List<OperationDescriptor>
suspend fun prepare(command: OperationCommand): OperationPlan
suspend fun execute(
plan: OperationPlanRef,
authority: OperationAuthority,
): OperationReceipt
}
A receipt identifies the command, target revision, executor, timestamps, result, logs, and artifact
references. It also distinguishes a request accepted by a cloud API from the later observation that the
intended resource became healthy. Operation execution does not silently rewrite the declared model to
match whatever happened.
A native application module has no reason to receive these administrative capabilities. Workbench and
deployment runtimes use separate scopes. A source scanner that discovered a legacy service can expose
source navigation without automatically gaining permission to redeploy it.
19.6 Federated consistency and bounded materialization
Each provider has its own cursor and refresh semantics. A system query can return a vector of watermarks
and identify stale or unavailable sources. Analyses that tolerate eventual consistency can proceed with
that evidence; analyses requiring a coordinated cut need a stronger acquisition protocol. There is no
globally atomic snapshot merely because a registry assigned the response one identifier.
A large installation can partition the registry by project, tenant, authority, or domain, with cached
summaries at higher levels. A query requests the relevant subgraph and explicit boundary summaries.
Cross-project navigation resolves those summaries on demand. This mirrors the logical principle of open
modules: a useful high-level view depends on interfaces and traceability, not on eagerly loading every
implementation and observation.
50
Page 51
Extracted text for page 51
Reaktor: An Extensible Software Engine Technical preprint
20 Identity, tenant isolation, secrets, and encrypted communication
These concerns share graph relationships but protect different boundaries. Authentication establishes
who is acting. Authorization determines permitted operations. Tenancy separates customer scopes and
resource budgets. Secret distribution supplies credentials to authorized runtimes. End-to-end encryption
restricts which endpoints can obtain content. None substitutes for the others.
20.1 A full-stack authorization engine
The Reaktor auth design distinguishes identity, external provider account, principal, application
membership, tenant/context, session, tokens, and policy. The reported JVM composition root is
AuthRuntimeGraph; transport adapters produce AuthContext, and shared authorization primitives
evaluate requirements [16]. A product’s sign-in button, provider exchange, rotating session, Worker
verifier, and service handler can therefore belong to one module without executing in one process.
An invocation must derive its authenticated subject and authority from a trusted boundary. A user-
controlled identifier, an internal URL, or a service binding is not sufficient evidence of end-user permission.
Delegation distinguishes the user subject from the service actor and checks audience and scope at the
receiving boundary. Local calls retain enforcement requirements when a deployment removes a network
hop.
The graph records which operation requires which policy and where enforcement occurs. A coverage
pass can detect a missing modeled enforcement path; runtime authorization still depends on request values
and current policy state. A source-declared effect summary remains an assumption unless encapsulation,
implementation analysis, or conformance establishes it. Revocation and authorization-data freshness are
therefore protocol requirements, not static labels.
20.2 Tenancy has four independent obligations
The multitenancy design separates isolation, fairness, residency, and lifecycle. Its initial enforcement
example is tenant-aware graph querying; the broader model is a proposal to propagate and enforce scope
across all relevant adapters [77].
Obligation Reference enforcement Graph-visible consequence
Isolation Scoped stores, database policies, No unmediated cross-tenant access path
tenant-qualified object and actor keys in the analyzed scope
Fairness Quotas, admission control, partition One tenant cannot consume an
budgets and cells unbounded share of a declared resource
Residency Placement and data-transfer policy Authorities, replicas, backups and
observations obey the selected region
rules
Lifecycle Onboard, configure, export, erase and An operation plan accounts for each
retention operations relevant store and external effect
Table 8: Tenant isolation is not merely a predicate on a query. Each obligation needs its own implementation and
evidence.
A tenant chosen by a client is an input to authenticated scope resolution, not an unforgeable capability
by itself. Mandatory query parameterization can help, but a text check for a tenant token is not a general
proof of query isolation. The enforced store interface, database policy, credential scope, and administrative
escape hatches define the real trust boundary. This specification retains the source’s isolation objective
without upgrading its initial mechanism into a stronger proven guarantee.
51
Page 52
Extracted text for page 52
Reaktor: An Extensible Software Engine Technical preprint
Pooled, bridged, and dedicated deployments are realization alternatives. Moving a tenant between them
is a data and traffic migration with cutover obligations, not a change to a display badge. Deletion similarly
accounts for caches, derived datasets, retained backups, legal holds, and external recipients. The model
should expose residual retention rather than imply that deleting one primary row erases the system.
20.3 Secrets are referenced in the graph and materialized at targets
The existing secrets design provides SecretRef, SecretStore, provider adapters, and a GCP Secret
Manager reference profile. Its planned materializers distribute target-specific values to Workers, k3s, CI,
or local development while keeping version and synchronization metadata visible [78].
The graph holds references, consumers, required versions, delivery policy, and operation evidence—not
raw values. A cache ledger identifies which target has which provider version. Rotation is a coordinated
operation over consumers, deployment, and revocation. A successful write to the secret manager does
not establish that every consumer adopted the new credential. A rolling compatibility interval may be
required.
Tool output, exception formatting, traces, source snapshots, and agent context must respect redaction.
A typed secret wrapper is not sufficient if a generic serializer or debug logger reveals its payload. Local
and production credentials need distinct authority. A development profile must not gain production access
merely because its dependency graph matches production.
20.4 MLS and end-to-end encrypted conversations
The security design selects MLS++ as the cryptographic engine behind a stable native boundary. Its
principal implementation obligation is durable encrypted state: create a group, persist, restart, import
the state, and correctly process subsequent messages and membership changes [79]. This subsystem is
distinct from sign-in and server authorization.
MLS specifies authenticated group key establishment with forward secrecy and post-compromise
security under its threat model. Groups evolve through epochs; membership changes and commits establish
new key state. It separates the authentication service from the delivery service, with confidentiality
designed to survive a compromised delivery service under the protocol assumptions [80]. Reaktor should
reuse that protocol rather than invent cryptography from graph connectivity.
The application graph represents group identity, device membership, protocol version, state ownership,
delivery relationships, and relevant operations. It does not expose secret tree material or epoch secrets
to the workbench. A publication hyperedge can describe the participant relationship, but it does not
itself implement MLS group agreement. The native crypto engine remains responsible for its protocol
transitions.
A recovery implementation must prevent inconsistent or stale state from causing unsafe key reuse
or divergent membership handling. Snapshot import/export, native ownership, error handling, secure
storage, and mixed-version compatibility are explicit conformance targets. Their successful tests do not
establish a new cryptographic proof.
The product consequences are material. Server-side content moderation, searchable plaintext analytics,
and ordinary content-bearing push payloads cannot silently coexist with end-to-end confidentiality. A
product must choose compatible mechanisms—for example client-side processing, minimal notifications,
explicit user reporting, or an explicitly identified additional endpoint. Metadata can still be sensitive. The
graph’s value is to make the conflict visible before implementation, not to make incompatible promises
simultaneously satisfiable.
52
Page 53
Extracted text for page 53
Reaktor: An Extensible Software Engine Technical preprint
21 Application protocols: work, mesh, notifications, and entry
A reusable application engine must account for the operating system and the user’s interaction lifecycle,
not only server requests. Background tasks, notifications, live peer sessions, and external navigation are
separate mechanisms with different completion and failure contracts. Their common graph representation
connects them without treating them as interchangeable transports.
21.1 Background work is not a durable server workflow
The existing reaktor-work facade wraps a KMP background-task implementation through TaskManager
and a Feature.Work slot. The module documentation explicitly separates platform tasks from broker
jobs, durable workflows, actor alarms, and control-plane commands [81]. A shared API must retain those
distinctions.
Android’s persistent-work facilities and Apple’s background execution strategies illustrate why. Work-
Manager supplies persistent scheduling mechanisms on Android; Apple assigns background execution
opportunities according to the selected API and operating-system policy [82, 83]. A portable periodic
request therefore cannot promise execution at an identical exact interval on every target.
A proposed task descriptor includes payload schema, unique-work key, constraints, scheduling intent,
expiry, retry requirements, and an operation-level idempotency scope. A run records actual admission,
attempt, cancellation, and terminal outcome. If the host cannot satisfy a hard deadline, the planner rejects
the profile or requires a suitable server handoff. A coroutine timer is not upgraded to durable work by
placing it inside a node.
For the photograph feature, a pending local transfer can be persisted and retried when the platform grants
execution. Once durable remote admission occurs, server-side processing belongs to the bus/workflow
profile. The UI shows which stage owns progress. Cancellation of local waiting work is not proof that an
already accepted server operation was cancelled.
21.2 Durable bus and live mesh
The bus design uses typed envelopes, subscriptions, retry policy, outbox handoff, deduplication, dead
letters, and replay over broker adapters. The mesh design owns live peer/session/media topology: signaling,
ICE state, TURN credentials, SFU routing, media tracks, data channels, and disconnect handling [84, 85].
A call room can use a Durable Object as a session directory, a service operation to authorize entry, and
a WebRTC realization for live traffic. The media stream need not become one database row per packet. A
fact such as “the session ended” can enter a durable bus or product transaction when the product requires
an auditable record. Realtime presence and durable business history remain different data.
The graph exposes participant roles, session identity, selected transport, credential expiry, stream
requirements, and observations such as latency or loss. A telemetry edge records an observation; it does
not become proof that every packet followed that route. Reconnection and failover policies must state
which state can be reconstructed and which observations are ephemeral.
21.3 Notifications as a full-stack feature
The notification design offers a particularly clear engine example: native permission and token lifecycle,
typed notification intents, durable cloud intake, fanout, provider attempts, receipts, and tap/action routing
belong to one feature family [17]. Its reference cloud design puts operational state in D1, delivery work
in Workers/Queues, coordination where needed in Durable Objects, and FCM credential brokering in a
narrow JVM service. These are design choices for the reference profile, not kernel requirements.
53
Page 54
Extracted text for page 54
Reaktor: An Extensible Software Engine Technical preprint
The lifecycle is
Intent → DurableIntake → Fanout → ProviderAttempt
→ DeviceObservation → UserInteraction.
The states are not equivalent. FCM documents that a returned message identifier means acceptance for
delivery, not confirmed arrival at a device; delivery can be delayed or expire [86]. Reaktor must not mark
a notification “seen” because a provider request succeeded.
A notification definition links content schemas, category/actions, audience policy, expiry, grouping,
and a typed application action. Native adapters map those declarations to platform behavior. The product
supplies interruption policy, consent, privacy, and recovery. Retries deduplicate the intended protected
effect where the chosen provider and storage contracts permit it; they do not invent universal exactly-once
presentation.
21.4 External entry uses the same route contract
The deep-link design derives a route index from the application graph, resolves a permitted URI, constructs
a navigation plan, collects guards, and defers entry when authentication or initialization is incomplete.
Android intents, iOS URL/user-activity callbacks, browser locations, desktop arguments, and notification
interactions become thin ingress adapters [87].
The proposed pipeline is
ExternalInput → Parse → ValidateOrigin → ResolveRoute
→ Authorize → PlanBackStack → Activate.
An external link is untrusted input. Parsing, host allowlists, parameter validation, current resource
authorization, and duplicate/cold-start handling belong to separate checks. A route-level login guard does
not replace server-side authorization for the resource displayed by that route.
For a notification opening a conversation, the pending navigation intent survives the required login step.
The plan creates a meaningful back stack rather than opening an orphan screen. Platform association files
and browser-history integration remain real deployment/configuration outputs. Reaktor’s advantage is
deriving them from a known route surface where supported, not eliminating platform requirements.
21.5 Cross-subsystem behavior remains explicit
A single product journey can traverse all four mechanisms: a background upload commits a message; a
durable publication starts notification delivery; a tap enters a guarded route; a live session then carries
presence. Each component owns its own lifecycle and evidence. The feature graph lets the author inspect
the transitions and test their composition without forcing one universal scheduler or completion notion
over the entire journey.
22 Polyglot execution, Switchboard, and the UI engine
22.1 Execution domains and artifacts
Hermes is an execution domain, not merely an update-delivery mechanism. An artifact identifies
implementation bytes, format, entrypoints, and requirements; a loader determines whether a runtime can
instantiate it. The FFI realizes supported graph interactions crossing native, Kotlin, Hermes, and other
language boundaries [88, 26]. Port meaning remains signature, protocol, and role.
The host exports a contract manifest covering graph interfaces, bridge ABI, engine/build compatibility,
state protocols, and optional UI protocols. The artifact declares its requirements. A valid graph with an
unsupported implementation artifact is inspectable but not executable on that host. A manifest cannot
supply an absent native capability merely by naming it.
54
Page 55
Extracted text for page 55
Reaktor: An Extensible Software Engine Technical preprint
22.2 Switchboard as a language-bridge profile
The canonical FFI design uses five terms: Frame, a versioned boundary message; Cell, an addressed
implementation with a declared execution profile; Switch, a per-runtime router; Trunk, a link between
routers; and Wire, an in-flight conversation [26]. These are realization concepts underneath the logical
graph. They do not replace nodes, ports, and edges.
A native Kotlin caller can address a C++ component through JNI or cinterop. Hermes can reach it
through JSI. A stable C ABI can support further language bindings. Network adapters can terminate
the same logical operation through an appropriate remote protocol. The design provides one family of
contracts across these paths without claiming identical locality, latency, aliasing, or failure behavior.
JNI / cinterop JSI
Kotlin runtime Native switch Hermes runtime
typed end- C++ imple- dynamic im-
point bindings mentations plementations
transport C ABI
JVM / remote host Other language host UI host protocol
service realization supported C owned sub-
ABI binding tree commits
Figure 5: A proposed Switchboard realization family. Logical endpoint identity survives the selected path; each
trunk retains its own ownership, scheduling, and conformance requirements.
The source’s four RPC shapes—unary, server-streaming, client-streaming, and bidirectional streaming—
form a useful call-profile family. They are not a replacement for the broader graph profiles, including
local references, revisioned state, and collective publication. Actor-shaped cells are appropriate for
exclusive state; a stateless direct handler need not acquire an unnecessary mailbox. Appendix F records
this deliberate alignment between the FFI design and the graph model.
22.3 Frames, schemas, and ownership
A dispatch header identifies runtime/boundary generation, registry revision, endpoint slot, invocation,
sequence, and frame kind. Compact slots are local indices; stable graph IDs remain in descriptors and
diagnostic mappings. A delayed callback cannot interpret a retired generation’s slot in the current dispatch
table.
Frame kinds cover request, item, demand, result, error, cancellation, and terminal acknowledgement as
required by the profile. A bounded stream declares whether credit counts items or bytes, how ownership
transfers, and how duplicate or late terminal frames are handled. Returning capacity both on timeout and
on eventual completion would violate the resource-accounting invariant developed in Section 14.
The FlexBuffer design distinguishes generated exact-layout access from the keyed serialization fallback.
The reported implementation does not establish negotiated layout compatibility for independently deployed
endpoints [89]. A proposed positional fast path therefore requires an exact accepted schema/layout
fingerprint before decoding. Otherwise it uses a compatible fallback or rejects the connection. Self-
describing bytes do not make unchecked positional access evolution-safe.
Borrowed buffers are valid only within their declared lifetime. Large media can cross through owned
handles or streaming references where the host supports them; a process-local pointer is not a portable
remote handle. Batching reduces repeated bridge crossings but adds buffering and latency. Synchronous
native calls must respect thread affinity and reentrancy rules; a synchronous cycle across runtimes can
deadlock. General application effects should prefer explicit asynchronous contracts unless the profile
establishes stronger conditions.
55
Page 56
Extracted text for page 56
Reaktor: An Extensible Software Engine Technical preprint
22.4 One UI vocabulary, several expert frontends and renderers
The UI and React–Compose designs distinguish an authoring frontend, an internal host representation,
rendering, and application orchestration [90, 91, 92]. React can express dynamic composition; Compose
can express native composition. A supported frontend adapter emits batched mutations into an owned
host-tree boundary. Renderer-facing snapshots derive layout, accessibility, event routing, and inspection
data. The graph owns feature structure and navigation; the host tree owns the corresponding UI subtree.
The proposed path is
React HostConfig or Compose Applier → validated TreeOps batch
→ owned HostTree → derived ShadowSnapshot
→ native Compose / DOM realization and inspection.
This is a target interop architecture, distinct from the existing workbench’s shared domain model with
separate React and Compose renderers. Neither existing code sharing nor a Hermes boot experiment
proves that a general custom reconciler already exists.
22.5 Ownership, events, state, and navigation
Each subtree has one structural owner. A parent may mount a child boundary and pass permitted values,
but cannot mutate the child’s internal tree directly. A mutation batch carries boundary identity, generation,
and commit sequence. Validation rejects stale generations, invalid parent/child changes, and undeclared
component properties before renderer publication.
Event handlers cross through registered references with lifetime and permission scopes, not serialized
closures. A click invokes a graph action or an owned local handler. High-rate gesture state and visual
feedback can remain native. Durable product state should normally reside in an actor or store outside a
replaceable React closure; the dynamic UI observes it through a revisioned state contract.
Routes, current back stacks, UI trees, and dependency graphs remain distinct. A route can activate a
screen whose render subtree changes frequently without changing architectural topology. Desktop joins
these structures through stable mappings rather than promoting every frame mutation into a system-graph
transaction.
22.6 Tactile behavior and design-system contracts
The UI design proposes typed tokens, component capabilities, switchable design languages, native
animation, haptics, shaders, and adaptive panes [90]. Its practical engine value is that interaction
quality becomes reusable infrastructure rather than per-screen gesture and timing code. A design-system
component can expose permitted properties, action events, accessibility behavior, renderer support, and
fallback tiers.
A spring or field simulation is an implementation technique for visual response, not a reason to run
per-frame physics over the global application graph. Frame-local work stays with the renderer’s scheduler
and memory model. Reduced motion, unavailable haptics, thermal limits, and renderer capability are
normal strategies. A feature remains usable when an optional effect is unavailable. Accessibility semantics
and input correctness are part of the component contract, not decorations added after the visual design.
22.7 Runtime management and replacement boundaries
A Hermes realization qualifies engine, compiler, bytecode format, embedding ABI, and bridge to-
gether. React Native’s bundled-Hermes design illustrates why a nominal engine name is insufficient for
compatibility [93]. Reaktor needs its own tested embedding profile.
56
Page 57
Extracted text for page 57
Reaktor: An Extensible Software Engine Technical preprint
A runtime manager tracks artifact generations, boundary membership, and owned resources. It does
not allocate one engine per graph node. Several boundaries may share an engine when their loader and
lifetime contracts permit it. Shared module caches, globals, callbacks, or native handles can instead
require replacement as one group. Packaging segmentation is not proof of independent unloadability.
UI boundaries, runtime instances, update regions, and security domains can be related without being
identical. A separate Hermes instance can improve lifecycle isolation, but is not by itself a complete
sandbox for hostile code. Supported replacement requires the state, lifetime, authorization, and recovery
protocol in Section 26.
23 Build, cloud, observation, and reproducible development
23.1 Dependeasy publishes build facts; tools execute them
Dependeasy’s existing role includes KMP conventions, Android/iOS native integration, dependency and
toolchain policy, cinterop generation, and JavaScript package outputs. The build-tools design extends it
into a producer of versioned target, source-set, artifact, test, and tool requirements for the CLI, desktop,
agents, and CI [5, 19]. A provider should consume authoritative build-model facts rather than repeatedly
guessing them from filenames when those facts are available.
A proposed build-target descriptor identifies source inputs, dependencies, toolchain, outputs, host
requirements, tests, budgets, and supported operations. Gradle remains the Kotlin build system; CMake
and platform toolchains remain native executors. Vite/Metro/Wrangler, Xcode/Fastlane, and test tools
retain their own appropriate responsibilities. The engine supplies a coherent discovery and operation
model, not a replacement compiler for every target.
The Reaktor CLI is the terminal projection of that catalog. Its source-reported implementation discovers
and runs tasks from existing project files; the complete manifest-backed convergence and authorization
pipeline remain proposed [20]. The same task identity should eventually resolve from a terminal command,
desktop button, or agent invocation. A successful process exit, produced artifact, and deployed healthy
instance remain distinct outcomes.
23.2 A release is a dependency-aware operation plan
Dagger provides programmable container-based pipeline execution, and Pulumi’s Automation API
provides programmatic control of infrastructure plans and updates [94, 95]. Reaktor’s reference design
composes such tools with Worker and mobile release executors [6]. A pipeline that calls a host-only
signing tool still needs an appropriate host runner; reproducibility does not erase platform requirements.
A release selects compatible code, schemas, policies, resource configuration, and dynamic-update
artifacts. Its plan orders operations and records approval, expected base revisions, and recovery conditions.
Expand–migrate–contract changes preserve mixed-version compatibility where required. The plan reports
partial completion rather than pretending a fleet rollout was one atomic graph mutation.
23.3 GCP cells and attached customer environments
The reference cloud design chooses regional k3s cells on GCP, with Reaktor-managed and customer-owned
deployment options. A cell is an execution and authority boundary, not one node in a geographically
stretched cluster. An outbound cell agent reports inventory and applies signed scoped operation plans; the
general registry and managed-cell control loop are design targets [96].
57
Page 58
Extracted text for page 58
Reaktor: An Extensible Software Engine Technical preprint
data class CellBinding(
val cell: CellId,
val ownership: OwnershipRef,
val region: RegionId,
val authority: DelegatedAuthorityRef,
val permittedOperations: OperationPolicyRef,
val observedRevision: ObservationWatermark,
)
The control plane owns intent, policy, and operation history. The cell retains enforcement over its
permitted resources. A disconnected agent cannot assume unlimited offline authority; its plan validity,
expiry, idempotency, and replay handling are explicit. Local workloads should continue within their
existing contracts when the management plane is unavailable. This is a control-plane design obligation
rather than a claim of automatic outage independence.
Cloudflare Workers and associated resources remain a separate execution plane connected by service,
bus, and data contracts. Supabase and other providers retain their own authority and operations. A
configuration importer proves what a file declares; only an appropriate provider observation can confirm
existence or health. The graph records both and exposes drift.
23.4 Signals belong to contracts, not only dashboards
The analytics/telemetry design distinguishes app-owned product events, framework telemetry, performance
measurements, and operational audit. Each has a schema, producer, privacy policy, and purpose [97]. A
product event catalog can reject forbidden payload fields before emission. A release identifier and logical
operation identity connect a signal to the system without requiring every invocation ID to become an
unbounded metric label.
The performance design supplies collectors, budgets, report models, and upstream profiler/test
integrations. Its target path connects platform reports and runtime signals to OTel and the selected
observation backends, including the Grafana family and analytical stores where appropriate [98, 71].
Existing profilers remain authoritative for their measurements. Reaktor normalizes references, context,
and findings; it does not claim to replace Instruments, Perfetto, JFR, or browser profiling.
A journey SLO links user-visible success to participating components. The notification example
distinguishes accepted intent, provider acceptance, known delivery, and tap. An ingestion pipeline also
observes itself: queue age, rejected events, dropped telemetry, exporter state, and source watermarks. A
silent dashboard is not evidence of a healthy system. The workbench should connect missing observations
to the corresponding producer and pipeline dependencies.
23.5 Development profiles before production mirroring
The Shadow Dev design begins with isolated development application IDs, auth scope, Worker bindings,
and data stores, then grows toward captured traffic, moving baselines, and disposable overlays [18]. This
order is important. Replay infrastructure built over production credentials is not a safe development
environment.
A capsule identifies a reproducible incident or test input: source/artifact revisions, selected observations,
permitted state references, nondeterministic inputs, and comparison policy. Materialization obtains a
bounded dependency closure, redacts according to policy, and creates an immutable base with writable
overlays. External effects are blocked or substituted by default. The selected seed or capture does not
establish full determinism if unrecorded clocks, remote responses, or scheduling decisions still matter.
The same capsule can serve a human diagnosis session, an agent task, a regression test, and a release
gate. Its evidence record distinguishes a matching output from a matching sequence of effects or a
58
Page 59
Extracted text for page 59
Reaktor: An Extensible Software Engine Technical preprint
performance comparison. Long-lived incident fixtures need explicit retention and privacy review; “pinned”
cannot silently mean legally or operationally permanent.
23.6 Operate existing systems without claiming complete ownership
A foreign service can enter through an interface specification, source scanner, trace, or resource importer.
Its declared knowledge tier determines which transformations the graph can justify, while an independent
operation provider and authority determine which actions are allowed [99]. A source-scanned service can
remain read-only in the authoring graph while an authorized infrastructure provider exposes a carefully
scoped restart. Knowledge and operational permission are distinct dimensions.
This supports incremental adoption: inspect first, attach typed boundaries, integrate tests and operations,
and replace implementation only where useful. The enterprise need not rewrite its estate into Kotlin to
obtain a connected service/resource view. It does need to pay for adapter maintenance, source mappings,
schema evolution, and the reconciliation of conflicting evidence.
24 Compilation and data-oriented implementation
24.1 Representations for different workloads
The architecture has an authoring representation, a semantic snapshot, and an execution representation.
Authoring favors typed classes, delegates, and navigable member references. The semantic snapshot
favors deterministic records, indexing, and revisioned queries. The execution representation favors direct
bindings, compact dispatch, buffers, and schedulers.
The snapshot is canonical for analysis of its revision, while the relevant source remains authoritative for
authored declarations. Generated files carry source mappings and fingerprints. Supported visual edits
produce source and semantic patches; re-elaboration confirms that the actual semantic change matches
the intended proposal. Arbitrary implementation code is not forced into a graphical syntax.
24.2 Record layout and indexing
A compact layout stores nodes, ports, edges, and incidences in separate typed tables. Hot port columns
include owner index, endpoint-type index, and flags. Binary edges can store two inline endpoint references.
N-ary edges use offsets into incidence storage. Reverse incidence indexes support port-to-edge traversal
without scanning every edge.
Stable IDs remain external identities. Dense indices are local to a storage revision or protected handle
generation. Reordering or compacting a table must not silently change a persistent reference. Names,
schemas, profile descriptors, and repeated policy sets can be interned. Documentation, source locations,
visualization coordinates, and evidence are cold side data.
Not all fields should be forced into one structure-of-arrays layout. A small binary-edge record consumed
as a unit may benefit from an array of structs; bulk owner or type scans may benefit from columns. Sparse
typed side stores support aspects that apply to a minority of entities. Creating a distinct archetype for
every combination of metadata would introduce unnecessary fragmentation.
MassEntity separates data fragments from processing [100]. Unreal’s Render Dependency Graph
records dependencies before compilation and execution [101]. The relevant design principle is workload-
specific representation with explicit dependencies, not adoption of an entire game-engine object or
scheduling model.
59
Page 60
Extracted text for page 60
Reaktor: An Extensible Software Engine Technical preprint
24.3 Snapshots and mutation cost
Semantic immutability does not require copying the whole graph. Chunked copy-on-write tables, persistent
indexes, or a compact base plus deltas can publish revisions while sharing unchanged data. Frozen
analysis snapshots can use compressed adjacency ranges. Highly mutable editor state can use a different
representation with the same abstraction function.
A storage implementation has an abstraction function 𝛼 mapping physical records to the semantic
model. The key refinement obligation is
𝛼(applyStore(𝑆, Δ)) = applyModel(𝛼(𝑆), Δ), (19)
for admitted patches, together with preservation of published-revision isolation. Temporary allocation
strategy is irrelevant to port ownership provided Equation 6 and the decoding relation remain true.
24.4 Compiled dispatch
Binding produces an invocation plan for a caller or participating endpoint. The plan selects a direct
handler, a codec/transport path, a recipient-selection structure, or an FFI entry. Applicable authorization
and instrumentation are compiled into the plan or invoked at explicit enforcement points.
An ordinary call should not rediscover its provider through a graph traversal. The existing consumer
implementation already caches a local target [9]; the richer model must preserve an equivalent direct path.
Where fixed bindings and proof obligations allow it, code generation can specialize or inline the dispatch.
Dynamic update boundaries retain an indirection deliberately, because that indirection is part of their
lifecycle semantics.
Kotlin wrappers can expose typed handles, but value classes do not by themselves establish zero
allocation across generic or foreign-function boundaries. Runtime-specific benchmarks determine
representation choices. Readable interfaces and data-oriented storage are compatible; neither requires
exposing raw arrays to application authors.
24.5 Lifetime, concurrency, and payload ownership
Published graph and execution bindings must form a compatible revision. Readers pin the relevant revision
or use a documented consistency mode. Retired handlers, buffers, and native resources are reclaimed only
after all protected users have released them. Acquire-and-pin must be safe against concurrent retirement;
a plain pointer load followed by an unprotected reference increment is insufficient.
Payload contracts distinguish immutable shared values, transferred ownership, and borrowed views. A
borrowed buffer cannot be retained across an asynchronous boundary beyond its lifetime. Broadcasting a
mutable reference to several receivers changes aliasing semantics unless the contract permits it. Zero-copy
paths are valid only when representation, synchronization, and ownership requirements hold.
Concurrency can be partitioned by project, module, or actor ownership. A global lock on every
operation would defeat the execution/control separation. Conversely, uncontrolled lock-free mutation is
not an architectural goal: synchronization is chosen to preserve the explicit revision and lifetime contracts.
24.6 Performance claims and measurements
Performance is an empirical obligation. The evaluation compares current direct ports, the proposed
compiled bindings, and representative adapter paths on each supported runtime. Measurements include
allocations, retained memory, direct-call overhead, serialization cost, graph traversal, patch validation,
snapshot publication, high-degree membership updates, and workbench query latency.
Memory and latency under skewed degree distributions matter more than uniform synthetic graphs
alone. Large actor groups and subscriptions require tests of lazy membership, incremental indexes, and
60
Page 61
Extracted text for page 61
Reaktor: An Extensible Software Engine Technical preprint
partition-local queries. Sparse incidence representations leave open the use of bulk graph-processing
backends, but no GPU or sparse-linear-algebra dependency is required for ordinary execution.
24.7 Measured realization rather than representation fashion
The reference implementation’s generated FlexBuffer coders, broad serializer fallback, and caller-owned
buffer paths illustrate why one representation need not serve every workload. The source performance
guide distinguishes jointly deployed exact-layout payloads from independently evolving wire or storage
contracts [89]. Its reported measurements are not reproduced here. A graph compiler can select a qualified
codec profile, but only after compatibility requirements and buffer lifetime permit it.
The same principle applies to graph storage. Binary edges can use two inline endpoint slots; n-ary
edges can use ranges in incidence storage. A typed incidence view presents both uniformly to algorithms.
Sparse facets do not require a separate object map on every node. None of these choices changes node
ownership or makes a rendered scene the canonical graph. Encoding and patch application must preserve
the semantic abstraction, and benchmarks must include incremental edits, skewed fanout, and retained
revisions rather than only sequential scans.
25 Hardware, resource budgets, and performance semantics
The semantic graph describes a system independently of its memory layout, but its implementation
runs on finite machines. CPU caches, memory bandwidth, scheduling, allocation, serialization, and
network propagation constrain attainable performance. Data-oriented design is valuable when it aligns
representation with actual access patterns; it is not a rule that every object must become a column.
25.1 The cost of following a relationship
An object-oriented graph often stores references from node to port to edge to another port. This is
convenient for mutation and direct binding, but a large analytical traversal can touch many separately
allocated objects. An indexed representation can place owner, endpoint-type, and incidence records in
compact arrays. A query scanning only owners and roles then avoids loading labels, source locations,
serializer objects, and UI metadata.
The benefit depends on workload. A binary call that already holds its implementation reference may
become slower if it is forced through several array lookups. A small adjacency record whose fields
are always used together may favor an array-of-structs layout. A bulk type-checking pass may favor
separate columns. The semantic model should admit both representations and require correctness of their
mappings rather than prescribe a single universal layout [102].
25.2 Bandwidth and operational intensity
For an appropriate computational kernel, the Roofline model bounds attainable throughput by compute
capacity and memory bandwidth multiplied by operational intensity [103]:
𝑃 ≤ min(𝑃 𝑝𝑒𝑎𝑘 , 𝐵𝑚𝑒𝑚 𝐼), (20)
where 𝐼 measures useful operations per byte transferred. Graph analyses are often constrained by memory
access rather than arithmetic. Their irregular access patterns mean that a simple floating-point Roofline is
not a complete predictive model, but the underlying question remains useful: how much data must move
per useful result?
Suppose an illustrative analysis examines ten million records and reads 16 relevant bytes per record.
The minimum useful traffic is 160 MB. At a sustained 20 GB/s, reading those bytes alone takes at least 8
ms. This is a hypothetical lower-bound calculation, not a Reaktor benchmark. Random access, indexes,
61
Page 62
Extracted text for page 62
Reaktor: An Extensible Software Engine Technical preprint
synchronization, decoding, and output construction add costs. If the representation forces another 80
bytes of unrelated data through memory per record, no faster arithmetic instruction can recover the wasted
traffic.
This motivates compact indexes, hot/cold separation, interned contracts, and bounded result material-
ization. It does not imply that every analysis should be vectorized or sent to a GPU. Transfer and launch
overhead can dominate a small query.
25.3 Parallelism has a serial boundary
If fraction 𝑠 of a workload remains serial and the rest parallelizes perfectly across 𝑝 workers, the idealized
speedup is
1
𝑆 𝑝𝑒𝑒𝑑𝑢 𝑝( 𝑝) ≤ . (21)
𝑠 + (1 − 𝑠)/𝑝
This is Amdahl’s familiar bound under fixed-work assumptions [104]. For graph validation, an exclusive
commit step, a shared allocator, or a final global policy check can limit speedup even when local checks
run in parallel.
The architecture should separate parallel candidate analysis from short authoritative publication. It
should also avoid placing unrelated runtime data-plane operations behind the graph editor’s mutation
lock. A design with more threads is not necessarily a design with more throughput. NUMA placement,
cache-line contention, and redundant scans can consume the additional capacity.
25.4 Batching exchanges overhead for latency
A bridge call has fixed overhead and payload-dependent work. If fixed overhead is ℎ and 𝑏 records share
a batch, its amortized contribution is ℎ/𝑏 per record. However, waiting to collect the batch adds delay and
can increase retained memory. A scheduler can flush on a maximum size, deadline, frame boundary, or
explicit transaction boundary.
A UI tree-update batch should remain a coherent commit for one boundary generation. A sensor stream
may prefer bounded freshness over large batches. A durable ingestion path can tolerate more delay in
exchange for throughput. These choices belong in profile and execution-plan parameters, not a hard-coded
global batch size. Large blobs should normally cross the FFI through controlled handles or suitable shared
views rather than repeated encoding through a JavaScript object graph.
25.5 Queueing identities are not latency guarantees
Little’s law relates long-run average population 𝐿, effective arrival rate 𝜆, and time in a stable system 𝑊
under the appropriate assumptions: 𝐿 = 𝜆𝑊 [105]. If an illustrative stage sustains 200 admitted jobs/s and
the mean time spent in that stage is 0.05 s, it has 10 jobs in the stage on average. This does not establish
that ten threads are required, that ten buffer slots are sufficient, or that a tail-latency bound is satisfied.
Resource planning must distinguish concurrency, queued work, active service, and external waiting.
Asynchronous execution can have many waiting requests and few active CPU tasks. A time-window
measurement must account for work that began before the window or finishes afterward. A queue growing
without bound does not satisfy the stable operating assumptions used for the simple calculation.
The system graph should connect admission, measured backlog, service time, and capacity assump-
tions. An alert can then report whether delay is associated with saturation, failed consumers, missing
acknowledgements, or upstream retries. A topology picture alone cannot make this diagnosis.
62
Page 63
Extracted text for page 63
Reaktor: An Extensible Software Engine Technical preprint
25.6 Memory ownership and reclamation
A snapshot is immutable to readers, but its buffers and bound resources still have lifetimes. Publishing a
new snapshot and reclaiming the previous one are different events. Read-copy-update (RCU) explicitly
separates removal from reclamation and waits for protected readers before freeing retired data [106].
Reaktor can use an appropriate target-specific mechanism with the same obligation, without assuming
Linux kernel primitives apply unchanged to Kotlin coroutines or Hermes callbacks.
A reader that loads a pointer and only then increments a reference count may race with reclamation
between those operations. Acquire-and-pin must be one properly synchronized protocol. Long-lived calls
or sessions need ownership that remains valid across suspension. Deferred callbacks, queued events,
and borrowed native buffers must participate in the same lifetime accounting or be invalidated safely by
generation checks.
Garbage collection can preserve a managed object’s memory without preserving an external native
resource it references. Conversely, retaining an old generation indefinitely can prevent memory from being
reclaimed even when it is no longer reachable from new calls. The execution runtime needs accounting
for both kinds of lifetime.
25.7 A concrete snapshot layout budget
A deployment-local implementation can use 32-bit indexes when its admitted graph size fits that range,
while stable external IDs remain larger opaque identifiers. The choice is a capacity contract. A compiler
must reject an oversized snapshot or select a wider representation; truncating IDs is not an optimization.
A candidate layout for a binary edge stores two port indexes, a profile index, and a flags word. A n-ary
edge stores an incidence range plus its profile. The inverse port-to-incidence index is a separate derived
structure. Sparse side stores hold policy, provenance, and documentation fields. No performance claim
follows from this sketch until allocation, traversal, mutation, and retention are measured on the intended
targets.
Updates need peak-memory planning. If the active generation uses 𝑀𝑎 , the prepared candidate 𝑀𝑐 ,
the transferable state 𝑀𝑠 , and staging buffers 𝑀𝑏 , a coexistence plan may require approximately their
sum before reclamation. A boundary restart can be preferable when simultaneous generations exceed the
device’s budget. Update mode is therefore partly a resource decision, not only a semantic one.
25.8 Physical delay and placement
Information propagation has a physical lower bound. Ignoring routing and processing, a signal traversing
distance 𝑑 cannot arrive sooner than 𝑑/𝑐, where 𝑐 = 299 792 458 m/s in vacuum [107]. Real communica-
tion media and networks add propagation and queueing delay. A synchronous control loop cannot be
made arbitrarily responsive by a location-transparent API when its critical path crosses a distant network.
This observation favors placing latency-critical work near its state or physical process, while leaving
planning, analysis, and fleet coordination elsewhere. It does not dictate that every service must be
co-located: fault isolation, capacity, jurisdiction, and operational ownership can justify separation. The
graph’s purpose is to make these competing constraints inspectable and analyzable.
26 LiveUpdate: replacement of supported subgraphs
26.1 Delivery, rewriting, and activation
LiveUpdate coordinates replacement of a supported graph region and its implementation artifacts. Over-
the-air code delivery, referred to here as CodePush, is one delivery mechanism. Graph rewriting describes
the structural change. Activation determines whether and how the replacement becomes part of the
63
Page 64
Extracted text for page 64
Reaktor: An Extensible Software Engine Technical preprint
running system. These operations use the existing release, patch, artifact, and execution models rather
than a second update-specific graph.
Updateability belongs to module boundaries, artifacts, loader capabilities, and state contracts. It is
not a new dimension of every port. A native host can retain an unchanged service interface while a
compatible Hermes implementation behind that interface is replaced. Graph-only updates can select
existing implementations or alter supported wiring. They cannot instantiate code that the installed host or
supported interpreter does not contain.
26.2 Update regions and closure
An update region 𝑈 is an open subgraph whose externally relevant relationships are mediated by declared
boundary contracts or included in a coordinated replacement. Write the surrounding system as 𝐻 = 𝐶 [𝑈].
Replacement yields
𝐻 ′ = 𝐶 [𝑈 ′ ], (22)
with an explicit mapping from required old boundary endpoints to compatible new endpoints. Internal
identities can change. Required public identities remain stable or have a validated mapping; ports retain
unique ownership in both revisions.
Closure includes more than visible call edges. Artifact imports, shared module state, captured
implementation objects, callbacks, timers, subscriptions, borrowed buffers, and exclusive resource
ownership can prevent independent replacement. For requested changes 𝑆0 , a planner computes a
monotone closure such as
𝑈 ∗ = 𝜇𝑋. 𝑆0 ∪ 𝐷 unmediated (𝑋) ∪ 𝐷 coUpdate (𝑋) ∪ 𝐷 state (𝑋) ,
(23)
where each dependency function is defined by a supported runtime and contract profile. Stable compatible
boundaries stop expansion. The least fixed point is a closure under those declared rules, not a proof of
globally optimal packaging.
If the importer or runtime cannot account for a relevant escaping reference, independent replacement is
unsupported. The planner can enlarge the region, require a whole-runtime restart, or reject the update. A
rectangle selected on a canvas is not a closure proof.
A hyperedge crossing the region boundary retains its role and membership semantics. Replacing
one subscription implementation need not replace all publishers or subscribers. Changing a shared
coordination protocol, durable subscription identity, or incompatible event schema can require a larger
update group or a mixed-version transition.
26.3 Update kinds and activation modes
What changes, how it is delivered, and when it activates are independent fields. A release can change
configuration, graph structure, implementation artifacts, or state representation. Delivery may occur
through an application release, an OTA channel, a local development tool, or a server deployment.
Stateful migration is a separate dimension of the plan. Next-entry or boundary-restart activation can
still require state conversion. A runtime supporting bundle download may support only restart activation.
A portable node can be placed in a dynamically loadable domain only when a qualified compiler and
loader support its code and dependencies; the graph alone does not make it portable.
26.4 Host contracts, artifacts, and release mappings
A signed update manifest binds the expected base release, graph patch, artifact hashes, dependencies,
required contracts, host requirements, activation plan, state transition, and recovery plan. Host requirements
include relevant graph and FFI ABIs, engine/compiler compatibility, capabilities, and optional UI or state
protocols.
64
Page 65
Extracted text for page 65
Reaktor: An Extensible Software Engine Technical preprint
Activation mode Operational contract
Next entry The replacement is selected when a feature is next entered; an existing activation is not
changed implicitly.
Boundary restart The old region is disposed and recreated, with only explicitly preserved state and
resources retained.
Drain and swap Admission pauses, relevant work drains, state and ownership transfer, and the new
generation begins serving.
Versioned coexistence New work selects the candidate while permitted old work remains pinned to its
compatible generation.
Table 9: Activation modes are runtime capabilities. Versioned coexistence is not the default assumption for an
arbitrary bundle.
Expo’s runtime-version model provides a precedent for checking the compatibility of an update against
native code already installed in the application [108]. Reaktor refines that boundary through explicit
contracts and runtime requirements. Declaring a compatible version label is not a substitute for a correctly
maintained compatibility description.
System revision, artifact hash, boundary generation, state-schema revision, and UI commit sequence
remain distinct. A release records their compatible mapping:
𝑅 : BoundaryId −→ ( ArtifactHash, Generation, ContractRevision). (24)
Unchanged boundaries need not acquire a new artifact or generation. A code rollback is a new authorized
release decision selecting a compatible previous artifact, not acceptance of arbitrary stale metadata.
26.5 Eligibility and runtime readiness
For a region 𝑈, installed target 𝑇, activation mode 𝑚, and channel 𝑐, define
Eligible (𝑈, 𝑇, 𝑚, 𝑐) = Closed (𝑈) ∧ BoundaryCompatible (𝑈, 𝑇)
∧ LoaderSupports (𝑇, 𝑚) ∧ HostSatisfies (𝑈, 𝑇)
∧ StatePlanValid (𝑈, 𝑇) ∧ CoexistenceValid (𝑈, 𝑇, 𝑚)
∧ BudgetSatisfied (𝑈, 𝑇, 𝑚) ∧ Authorized (𝑈, 𝑇, 𝑐). (25)
Eligibility is distinct from reaching a safe point at time 𝑡. Static evidence can establish some terms;
others rely on certified runtime profiles or checked preconditions. Unknown evidence is not interpreted as
success. Resource-budget satisfaction can be rechecked during preparation. A supported update may
legitimately defer activation when a long-lived session prevents its safe point.
26.6 Preparation and effect isolation
The lifecycle proceeds through staged, prepared, ready, active, draining, and retired states, with explicit
rejected and failed states. Preparation verifies signatures and hashes, resolves dependencies, validates the
graph patch, creates the candidate generation, installs its restricted bindings, restores staged state, and
runs permitted probes.
Candidate evaluation can execute arbitrary initialization code. Consequently, preparation must restrict
effects, not merely hide the candidate from the UI. Production message consumption, external writes,
notifications, and ownership claims remain disabled until the relevant activation step. Staged migrations
write isolated state or use a backend-supported transactional protocol. A preparation environment with
unrestricted access to production state is not isolated simply because the candidate has not yet been
published.
65
Page 66
Extracted text for page 66
Reaktor: An Extensible Software Engine Technical preprint
Authentication of artifacts does not establish benign behavior. Capability restriction is enforced by the
host and its binding layer. A declaration of requested capabilities grants no additional authority. Existing
references, shared globals, and unsafe native entry points must also be included in the threat and isolation
model.
26.7 Generation-pinned execution
An update group publishes one immutable execution view. Admission atomically acquires and pins that
view. A request or coordinated unit of work carries the view through its relevant internal calls. Loading
a fresh binding independently at every call could produce an unsupported mixture even if each pointer
update were atomic.
Generation 𝑔
existing work drains
Boundary admission State and resources
acquire and pin view under declared ownership
Generation 𝑔 + 1
new work admitted
Figure 6: Versioned execution pins the appropriate work unit, not merely an individual dispatch lookup. Shared
mutable state requires a separate coexistence or handoff contract.
Calls return to their originating invocation. Streams retain or explicitly migrate their subscription and
checkpoint semantics. Sessions remain pinned, reconnect, migrate, or close under their protocol. UI
boundaries activate a coherent subtree and reject stale-generation commits. Durable workflows retain
compatible definitions or migrate at declared recovery points.
Proposition 26.1 (Generation isolation). Assume admission uses a linearizable acquire-and-pin operation
on a group execution view; work resolves relevant bindings only through its pinned view; a generation is
reclaimed only after its last protected user releases it; and external callbacks validate their registry and
generation. Then admitted work does not resolve a required binding through a reclaimed generation, and
publishing a replacement does not change the pinned binding view of existing work.
Proof. Acquisition selects one published view and protects it before retirement can reclaim it. Publication
changes the view selected by later acquisitions, not a previously acquired view. Binding resolution is
restricted to that view. The last-release rule prevents reclamation while such resolution is permitted.
A delayed callback without a valid protected generation is rejected rather than reinterpreted in a new
registry. □
The proposition concerns routing and lifetime. It does not imply that old and new code may safely
write shared state, that all calls terminate, or that code satisfies its declared behavior. The acquire-and-pin
implementation must itself avoid reclamation races and handle reuse.
26.8 Exclusive state and safe points
For exclusive stateful regions, coexistence requires a stronger contract or is disallowed. A drain-and-swap
protocol pauses new processing while retaining accepted work, drains the old writer, records a checkpoint,
migrates state if necessary, advances the enforced ownership epoch, and activates the replacement.
Buffered messages retain their delivery identities and ordering interpretation.
An old generation that remains alive cannot continue protected writes after ownership transfer. A
fencing check must be enforced by the resource owning the commit, not only by the caller’s in-memory
registry. If that resource cannot enforce the required handoff, the realization cannot claim exclusive-state
safety under concurrent generations.
66
Page 67
Extracted text for page 67
Reaktor: An Extensible Software Engine Technical preprint
Safe-point conditions are profile-specific. A UI boundary may require disposal of callbacks and
subscriptions. An actor may require no active transition. A stateful session may require an application-
defined handoff. Cancellation is not proof that an already issued remote effect did not occur.
26.9 State migration and recovery
State is classified as ephemeral, host-owned, exportable, or durable with a versioned schema. Host-owned
product state can outlive a replaceable Hermes generation [88]. This reduces handoff work, but does not
make rollback automatically safe: candidate code may have changed the state in a way an old artifact
cannot read.
A migration is a partial function with a precondition and a postcondition:
𝐼𝑜𝑙𝑑 (𝑠) ∧ 𝑃𝑟𝑒 𝑚 (𝑠) =⇒ 𝐼𝑛𝑒𝑤 (𝑚(𝑠)). (26)
The plan distinguishes activation compatibility from recovery compatibility. A reverse migration is optional
and must not erase valid new work. Additive schema evolution and explicit reader/writer compatibility
windows are preferred when available. Expo’s recovery documentation similarly distinguishes safe
rollback from cases requiring a forward fix after persistent-state changes [109].
Activation uses a crash-safe journal and an independently available recovery entrypoint. Every cut
between durable state writes, ownership changes, execution-view publication, and release recording has a
specified recovery action. Restart selects a generation compatible with the durable state and ownership
epoch, or enters a restricted recovery state. An in-memory pointer swap does not make those durable
operations atomic.
Repeated failure must not trap the application in a loop that prevents fetching or selecting a repair. A
known-good artifact alone is insufficient when its state contract no longer holds. The recovery record
therefore includes state compatibility and the permitted forward-repair path.
26.10 Packaging, memory, and update security
Content-addressed artifacts allow unchanged implementation objects to remain cached. The initial
supported packaging unit is a complete artifact per valid update boundary, with immutable shared
dependencies where the loader supports them. Chunking or bytecode segmentation can reduce transfer
size, but does not establish independent retirement of closures, globals, or callbacks.
Versioned preparation increases peak memory. The admission budget includes the old generation,
candidate, staging buffers, migration state, and deferred work. A target may choose restart activation
instead of coexistence when that budget is insufficient. Packaging optimization can consider download size,
restart cost, cross-boundary communication, and memory, subject to mandatory co-update constraints; no
universally optimal partition is assumed.
Update metadata must prevent mix-and-match artifacts and unauthorized rollback. TUF provides a
relevant model for authenticated targets, coherent snapshots, version checks, expiry, and key roles [110].
A production design must additionally specify root/key rotation, trust recovery, channel authorization, and
how offline targets handle stale metadata without silently abandoning security requirements.
Technical eligibility is separate from distribution-channel policy. Store-distributed applications remain
subject to the applicable restrictions on downloaded executable behavior [111, 112]. A Hermes-compatible
artifact is not automatically authorized for every release channel. Policy approval is represented as
attributable evidence rather than inferred from a runtime name.
67
Page 68
Extracted text for page 68
Reaktor: An Extensible Software Engine Technical preprint
27 A concrete LiveUpdate coordinator
Section 26 defines supported replacement. A coordinator implements that definition as a recoverable
protocol. Its job is not to make arbitrary code reloadable, but to preserve the selected graph, artifact, state,
and lifetime contracts during a supported transition.
publish new
execution mapping
call A pins generation 𝑔 release
call B pins 𝑔 + 1
time
old calls remain valid retire 𝑔 only when
all lifetime conditions hold
Figure 7: Versioned coexistence is a lifetime protocol, not only a change of an active pointer. Stateful exclusivity
can require a different, drain-and-handoff activation mode.
27.1 Durable decisions and transient preparation
The coordinator records a release decision separately from transient loader state. Useful states include
Proposed, Verified, Staged, Prepared, Quiescing, Activated, Healthy, Retiring, Complete,
and Failed. A crash can destroy a prepared runtime while leaving the durable release decision intact.
Recovery therefore reconciles the journal with actual runtime/artifact state rather than assuming that every
recorded step is still resident in memory.
interface UpdateCoordinator {
suspend fun assess(manifest: UpdateManifest): UpdateAssessment
suspend fun stage(approved: ApprovedUpdateRef): StagedUpdate
suspend fun prepare(staged: StagedUpdateRef): PreparedUpdate
suspend fun activate(
candidate: PreparedUpdateRef,
safePoint: SafePointEvidence,
): ActivationReceipt
suspend fun recover(journal: UpdateJournalRef): RecoveryResult
}
SafePointEvidence is issued by the runtime or state owner under the relevant protocol. It is not an
arbitrary boolean supplied by an agent. A stateful actor can establish that admission is paused, its current
handler finished, its mailbox ownership is accounted for, and the old writer is fenced. A UI boundary can
establish that a coherent replacement tree is ready and that its event namespace has a new generation.
27.2 A publication protocol
For a versioned, stateless update group, a simple conceptual protocol is:
68
Page 69
Extracted text for page 69
Reaktor: An Extensible Software Engine Technical preprint
1. Authenticate the complete release description and artifact hashes.
2. Check host contracts, capabilities, and update-region closure.
3. Load candidate code with production admission disabled.
4. Prepare candidate bindings, resources, and permitted probes.
5. Construct an immutable group execution view.
6. Under the publication protocol, replace the group’s active view.
7. Admit new work through the new view.
8. Retain old views while valid pinned work still references them.
9. Retire old resources after the reclamation condition holds.
A stateful update inserts checkpoint/migration and ownership transfer before admitting its new writer.
These additional steps can change the activation mode from coexistence to drain-and-swap. The system
should reject an incompatible mode rather than hide it behind the same activate() call.
The group view is the publication unit. Updating each endpoint separately can expose combinations
never checked together. Code that enters the group acquires a compatible view and uses it for the declared
unit of work. Cross-group calls require either compatible mixed versions or a larger coordinated group;
local pointer publication cannot create atomicity across independently deployed machines.
27.3 Crash cuts and recovery choices
Every durable step creates a failure boundary worth testing. A download can be incomplete; signature
verification can fail; candidate initialization can throw; state migration can complete before activation;
activation can succeed before a health receipt is recorded; old work can remain pinned after an operator
requests retirement.
The recovery rule depends on the last authoritative decision and the state contract. Before activation,
deleting an unused candidate may be sufficient. After activation with unchanged backward-compatible
state, selecting an authorized earlier artifact may be supported. After an irreversible state transition,
forward repair may be the only valid option. A recovery journal must identify which case applies rather
than unconditionally selecting the previous bundle.
A known-good bootstrap path should be independent of the replaceable feature it repairs. Repeatedly
starting the same failing candidate without changing recovery state produces an update boot loop. A
protected attempt counter and recovery decision can prevent that loop under a stated storage-failure model.
They do not recover a device whose trusted loader or storage has itself been corrupted beyond the assumed
boundary.
27.4 Callbacks, subscriptions, and native resources
A function exported from Hermes can outlive the call that acquired it through a queued callback or
subscription. The runtime must attach the callback to a boundary generation and either retain its
implementation or revoke it safely. Numeric dispatch slots are interpreted together with runtime, registry,
and generation identity. Recycling slot 42 for new code does not make an old callback to slot 42 valid.
Likewise, a native buffer borrowed by JavaScript cannot be released merely because the graph edge was
replaced. Borrowed lifetimes, copied values, and owned handles require distinct protocols. A generation
check prevents misrouting; it does not itself preserve memory that was freed too early. The lifetime
guarantee depends on ownership or protected reclamation in addition to checking identifiers.
For subscriptions, termination and resumption must define replay. Reconnecting at “now” can lose
events between generations. Reconnecting from the old checkpoint can duplicate events. A state or
stream profile can instead transfer a durable cursor and retain the necessary deduplication or gap-detection
semantics. The appropriate behavior is profile-specific.
69
Page 70
Extracted text for page 70
Reaktor: An Extensible Software Engine Technical preprint
27.5 Delivery optimization follows correctness
Content addressing can avoid downloading unchanged artifacts. Boundary-aligned packages can limit
how much code needs to be staged. Shared immutable libraries can reduce storage, while independently
replaceable mutable module state requires stronger loader support. None of these packaging optimizations
proves safe unloading.
The first deployment profile should favor simple, inspectable replacement units and bounded preparation
memory. Fine-grained segmentation, runtime pooling, predictive partitioning, and cross-generation
optimization are later refinements. They should preserve the same release and lifetime contracts and be
justified by measured costs.
An updateability query should return the supported modes and reasons: missing host capability,
incompatible schema, untracked callback lifetime, insufficient memory, state-migration requirement, or
distribution-policy restriction. The result is an engineering explanation, not a generic claim that JavaScript
can always be pushed safely.
28 Human and agent authoring
28.1 A common engineering surface
A human editor, command-line client, and software agent use the same semantic reader, operation catalog,
proposal protocol, and authorization boundary. They need not use the same interaction style. A human
can navigate spatially, read source, manipulate a Blueprint, or run a terminal command. An agent can
request a bounded working set and issue structured operations. Neither gains direct mutation authority
merely by learning an entity’s identifier [113].
A working set contains the selected feature, its public contracts, relevant boundary dependencies,
source locations, applicable constraints, available operations, and linked evidence. The query records
scope and freshness. Lexical search and implementation inspection remain necessary when the graph
lacks the behavior needed for a decision. A partial graph is useful context, but must not be presented as a
closed-world account of arbitrary application code.
For the photograph feature, an agent can discover the upload and messaging contracts, inspect the
existing actor, propose a moderation-pending state, identify affected consumers, and generate tests for
retry and expired-upload outcomes. A product developer decides the user-visible semantics and approves
the new behavior. A framework engineer reviews a new transport or lifecycle mechanism when the change
exceeds the available substrate. These responsibilities are determined by expertise and authority, not by a
rule that humans may only plan or that agents may only fill in code.
28.2 Proposals, checks, and receipts
A proposal names its base revision, source patch, intended semantic delta, affected scope, preconditions,
required permissions, and acceptance plan. Source elaboration checks that the resulting semantic delta
corresponds to the reviewed intent. Unsupported edits remain visible as source changes rather than
disappearing outside the review. Concurrent proposals are revalidated against the combined constraints;
disjoint text edits can still violate one architectural invariant.
Read, propose, apply, test, and operate are distinct authorities. Production deployment and authorization
administration require explicitly adopted policy; they are not consequences of permission to edit a feature.
The source control-plane design uses a critic that can withhold approval without applying changes
itself [113, 114]. A second model’s agreement is review evidence, not an independent proof. Protected
acceptance tests, policy definitions, credentials, and verifier configuration cannot be modified through an
ordinary feature-change grant.
70
Page 71
Extracted text for page 71
Reaktor: An Extensible Software Engine Technical preprint
An operation receipt records the resolved target and artifact, initiating principal, authorization decision,
executable action, environment, exit status, output references, and resulting observations. A build receipt
and a deployment-health receipt answer different questions. A successful command invocation does not
establish that the intended cloud resource is healthy. Bounded recipe execution in the documented DevOps
handoff is an early source example of this separation between planner, executor, and evidence [115].
Repository instructions, imported documents, and tool output are untrusted inputs to an agent. They
cannot grant authority or change the approved target. Typed tool schemas reduce ambiguity but do not
eliminate malicious arguments, unsafe sequences, or incorrect business decisions. Argument validation,
invocation authorization, isolation, resource budgets, and attributable review remain necessary.
28.3 Application agents are also application components
Development agents change software; product agents participate in the software’s behavior. The latter
require ordinary service contracts, data permissions, deadlines, retries, budgets, and observability. The
documented BestBuds proposal places a Koog-based orchestration loop on the JVM, with edge-side
prefilters and graph-backed tools, memory, and moderation outcomes [116]. This is a proposed integration,
not evidence that every agent loop already runs through Reaktor.
An application agent can be exposed as a service or actor-shaped component. Its internal strategy graph
is related to, but not identified with, the full application graph. A tool invocation can reach a typed Reaktor
operation; the operation’s authorization is enforced independently of what the model says. A structured
model response must still be checked against application invariants. Nondeterministic generation is an
explicitly recorded dependency when replaying a product workflow.
Browser-local assistance is a separate realization choice. The documentation distinguishes browser-
managed task APIs from application-managed WebGPU inference [117]. Both require feature probes,
download and memory handling, permissions, cancellation, and a fallback policy. Local execution can
reduce data movement, but does not prove a model trustworthy or suitable for authoritative decisions. A
capability profile can select local summarization while reserving another task for a remote service under
its own budget and privacy policy.
28.4 Reusable discoveries, not perpetual rediscovery
A successful agent-assisted change should leave durable engineering assets: source, contracts, tests,
examples, migration rules, and operational evidence. A newly implemented feature package becomes
discoverable to the next author. A counterexample can become a regression test. A repaired integration
can gain a provider conformance check. This is the connection between agent acceleration and engine
development: improvements become structured capabilities rather than remaining isolated generated
patches.
The interaction model follows the practical emphasis on usable tool interfaces and persistent feedback
in SWE-agent and long-running-agent harness work [118, 119, 120]. The next section defines the limits
of the resulting capability-growth claim. More automation can accelerate composition; it cannot establish
unprovided contracts or remove the need to validate a new mechanism.
29 Capability growth and the changing division of programming work
A platform can expand what applications are practical to build without changing the set of computable
mathematical functions. A native application language may already be Turing complete, yet an installed
application cannot necessarily load new feature code, invoke a robot actuator, stream a GPU buffer, or
participate in a particular authentication protocol. These depend on available mechanisms, permissions,
resource budgets, and supported realizations. This distinction makes the idea of adding a new “dimension”
to Reaktor precise.
71
Page 72
Extracted text for page 72
Reaktor: An Extensible Software Engine Technical preprint
Old mechanism set New mechanism Conservative extension
P 𝑐 and its laws P ′ = P ∪ {𝑐}
preserved realizations
Feasible systems under stated assumptions Feasible systems
S(P, E, B) S(P ′ , E, B)
Figure 8: Capability growth under a fixed environment E and budget B. A strict increase requires a witness that
the old mechanism set cannot realize within those constraints; a new API name alone does not establish it.
29.1 A realizable-system space
Let a platform description P contain a typed vocabulary, component implementations, protocol modules,
realization providers, runtime capabilities, and assurance rules. Let E describe the execution environment
and its available resources. A budget B can constrain memory, latency, operational cost, engineering
complexity, and deployment policy. Define
S(P, E, B) = {(𝐻, 𝜌) | 𝐻 is well typed, 𝜌 is supported, and the stated constraints hold}. (27)
This is a set of qualified architectural realizations. It is not automatically a vector space. Adding two
applications need not yield an application with a meaningful additive inverse; scalar multiplication of an
authorization protocol is undefined. Typed composition, refinement relations, and constrained search are
more appropriate mathematical structures.
A platform vocabulary can nevertheless act like a collection of generators. Registered components and
protocols are combined through permitted module composition, connection, hierarchy, and transformation
rules. The closure of these generators describes the systems expressible by those rules. A new generator
can create combinations that were previously unavailable. Existing frameworks already exploit this
principle through libraries, compilers, and plugin systems; Reaktor’s proposed distinction is to package
the relevant cross-system contracts and evidence with the mechanism.
29.2 Conservative extensions
An extension P ⊆𝑐 P ′ is conservative for a stated environment and budget when old well-formed
descriptions retain their meaning and supported realizations, the new mechanism is optional, and its
presence does not consume or revoke resources required by unchanged applications. Conservative
extension is a property to establish, not a default label for adding a plugin.
Proposition 29.1 (Preservation under conservative extension). If P ′ is a conservative extension of P for
E and B, then there exists an identity-preserving embedding
𝜄 : S(P, E, B) ↩→ S(P ′ , E, B). (28)
Proof. Map each old description and realization to its unchanged interpretation in the extended platform.
Conservativity preserves typing, supported bindings, behavior, and the relevant resource and policy
conditions. Distinct original descriptions retain distinct identities, so the mapping is injective. □
The proposition states an extension discipline. A stronger default security policy, an incompatible
compiler change, or eager allocation by a new runtime can deliberately break its assumptions. Such a
change may be justified, but it is a migration rather than a conservative expansion.
Strict expansion requires a witness relative to the stated constraints. Consider an installed host that
already contains qualified Hermes and FFI capabilities, while the original platform vocabulary exposes
only static-native artifact bindings. Under a requirement that the installed host binary remain unchanged,
72
Page 73
Extracted text for page 73
Reaktor: An Extensible Software Engine Technical preprint
an otherwise unavailable implementation update can become realizable when an extension adds the
checked artifact-loading and LiveUpdate protocols using those existing host capabilities. The witness
concerns the supported realization language, not a newly computable function. If the host lacks the
loader or bridge, a native host release must install it first; that changes E and is not an example of strict
expansion under an unchanged environment. Distribution policy and the resource budget must permit the
new realization in either case.
29.3 Where vector spaces are genuinely useful
Numerical design descriptors can live in a vector space. A feature map
Φ(𝐻, 𝜌) = (𝑚𝑒𝑚𝑜𝑟 𝑦, 𝑙𝑎𝑡𝑒𝑛𝑐𝑦, 𝑒𝑛𝑒𝑟𝑔𝑦, 𝑐𝑜𝑠𝑡, 𝑢 𝑝𝑑𝑎𝑡𝑒𝑆𝑖𝑧𝑒, . . .) ∈ R𝑑 (29)
can support measurement, optimization, embeddings, and comparison. Units must be retained or
normalized before combining coordinates. Some entries may be intervals, distributions, categorical
values, or unknown rather than reliable scalars. Feasible designs form a constrained subset, generally
nonlinear and discontinuous.
A newly supported mechanism may add a useful coordinate to the design process, such as update
granularity or a formally characterized timing profile. It can also enlarge the feasible subset in existing
coordinates: a more efficient codec can satisfy a latency budget without adding any new interface
shape. Linear independence of sampled feature vectors does not prove that two software capabilities are
semantically independent. Rank and basis terminology should be restricted to the numerical model where
those operations are defined.
This distinction strengthens the original intuition. The platform grows through reusable semantic
mechanisms, while vector and optimization methods help characterize the resulting design space. The
language of typed algebras explains composition; linear algebra explains selected quantitative analyses.
29.4 A capability package carries more than code
A reusable extension should include its endpoint and domain schemas, permitted compositions, imple-
mentation artifacts, realization support, lifecycle, failure semantics, resource ownership, migration rules,
source mappings, and tool operations. It should also include conformance tests, property obligations, and
evidence about supported guarantees. These items need not all be large. A pure formatter may require
little beyond types and tests; a durable workflow runtime requires considerably more.
For example, a robotics adapter is incomplete if it only exposes move(x,y). It needs the coordinate
frame, units, command lifetime, actuator authority, feedback protocol, failure behavior, and the safety
boundary within which commands are accepted. A dynamic-code extension is incomplete if it only
evaluates a bundle. It needs artifact compatibility, capability restriction, update closure, generation
routing, state handling, and recovery.
A human engineer or research team can identify the missing mechanism, build a proof of concept,
characterize its limits, and convert it into such a package. Once adopted, applications and agents can
compose it without rediscovering every integration detail. The reusable contribution is the mechanism
together with its conditions of correct use.
29.5 Human and agent responsibilities
The architecture should preserve several human responsibilities explicitly: deciding which problem is
worth solving, choosing acceptable risks and constraints, acquiring domain knowledge, recognizing
an inadequate abstraction, and approving changes to the platform’s trust boundary. These are design
responsibilities, not a claim that agents can never assist with them.
73
Page 74
Extracted text for page 74
Reaktor: An Extensible Software Engine Technical preprint
Agents are useful as candidate generators, implementers, search assistants, test authors, and investigators.
They can help find counterexamples and propose a better decomposition. They can also propose new
platform mechanisms. However, a capability extension can alter the set of permitted effects and the
meaning of verification. It deserves review at a different authority level from application composition.
The desired loop is not “humans specify everything, agents type everything.” It is iterative: a difficult
task exposes a missing abstraction; people and tools explore it; a precise contract and implementation
emerge; evidence identifies the supported domain; and the platform makes the result reusable. Subsequent
work can proceed at a higher level while still retaining access to the underlying implementation.
29.6 Evidence about agent environments
SWE-agent demonstrates that the interface through which a model navigates, edits, and tests a repository
affects software-engineering performance [118]. Anthropic’s long-running-agent report emphasizes
initialization, durable progress artifacts, incremental work, and end-to-end feedback [119]. OpenAI’s
harness-engineering report describes repository legibility, architectural constraints, isolated work environ-
ments, and tools as central parts of an agent-first development workflow [120]. These are precedents for
environment design, not measurements of Reaktor.
Reaktor can expose a bounded context package containing the relevant graph projection, source files,
contracts, applicable constraints, available operations, and evidence. It should retain lexical search and
ordinary source inspection. A graph record saying that a handler is idempotent cannot replace reading or
checking its implementation when that claim is not already established.
An agent’s context also has a budget. Returning the entire system graph increases noise and can
expose unnecessary information. A task-specific working set should include boundary summaries, proof
dependencies, and unknowns, with explicit expansion operations. The objective is sufficient context for
the task, not maximal context by byte count.
29.7 Faster generation shifts rather than removes bottlenecks
Suppose a development pipeline has proposal generation, implementation, verification, review, and
deployment capacities 𝜇1 , . . . , 𝜇 𝑘 . A simple flow model bounds sustained completed work by its limiting
stage. Increasing proposal throughput alone can enlarge the review backlog rather than increase accepted
changes. This is a modeling observation, not an empirical estimate of future productivity.
The graph can improve the limiting stages by narrowing test selection, attaching source-linked
counterexamples, preserving implementation intent, and showing which assumptions a change affects. It
can also make bad changes fail earlier. The value of formal methods grows when inexpensive proposal
generation creates many alternatives but only a subset can be safely integrated.
Test-passing and useful change acceptance are different outcomes. METR’s March 2026 study reports
a substantial gap between benchmark-passing patches and maintainer acceptance for the agents and
repositories it examined; the study’s scope does not establish a permanent limit on future agents [121].
Evaluation should therefore measure accepted changes, maintenance burden, regressions, and review
effort in addition to test completion.
29.8 Three trajectories, one robust architecture
Under an incremental trajectory, models improve unevenly and humans remain heavily involved in
implementation. Reaktor is useful through typed navigation, local checks, source-linked views, and
ordinary modular programming. Agent integration remains optional.
Under a strong-agent trajectory, implementation becomes cheaper and more parallel. Reaktor supplies
permissioned context, isolated execution, reproducible checks, structured proposals, and explicit approval.
The platform must prevent a proposer from silently weakening tests or policies to obtain a passing result.
74
Page 75
Extracted text for page 75
Reaktor: An Extensible Software Engine Technical preprint
Under a rapid-capability trajectory, agents contribute increasingly to runtime mechanisms, compilers,
and proof development. Reaktor’s extensible vocabulary and verification boundaries become more
important, because accepting a new mechanism changes what many applications can do. Mechanism
review, evidence provenance, independent checking, and compatibility policy remain necessary even
when the implementation process is highly automated.
These trajectories are scenarios rather than dated predictions. The architectural investments common
to all three are explicit interfaces, faithful source mappings, bounded context, reproducible execution,
scoped authority, and reviewable evidence. They do not depend on selecting a particular model vendor or
assuming an uninterrupted rate of model improvement.
29.9 Avoiding false confidence from multiple agents
Several agents can share the same mistaken specification, incomplete graph, or training-induced assumption.
Agreement among them is not equivalent to independent experimental replication or a proof. A critic can
be useful when it examines different evidence and applies a distinct review procedure, but an ensemble
vote should not replace a protected verifier or human authorization boundary.
The trusted base includes source elaboration, policy enforcement, model extraction, test infrastructure,
and evidence handling. An agent that can modify all of these can make an unsafe patch appear acceptable.
The platform should distinguish application edits from changes to the apparatus that judges them, and
audit the latter at an appropriate authority level.
The long-term opportunity is therefore a compounding engineering environment: improved models
accelerate work within explicit contracts, and improved human-designed mechanisms enlarge the supported
system space. The graph connects these contributions to their assumptions and implementations instead
of treating each completed code generation as an isolated artifact.
30 Assurance and formal guarantees
30.1 Claims, assumptions, and trusted boundaries
A formal claim has the form
𝑀 ∧ 𝐴 |= 𝜑, (30)
where 𝑀 is a specified model, 𝐴 environmental and implementation assumptions, and 𝜑 the property. A
guarantee about deployed code additionally needs a conformance or refinement relationship between that
code and 𝑀. Merely exporting source metadata into a graph does not supply it.
The trusted computing base depends on the claim. It can include parsers, schema elaboration, validators,
storage publication, code generators, runtime adapters, authentication, the update loader, native bridges,
and the verification toolchain. A certificate identifies which components are assumed and which have
supporting evidence. Opaque or unsafe escape hatches narrow the claim rather than disappearing from
the model.
30.2 Structural and relational checks
Exact graph algorithms establish ownership, referential integrity, cardinality, connectivity, and dialect-
specific acyclicity for the selected revision. Relation-based analysis can check module closure, declared
authority, and policy structure. Alloy is useful for exploring candidate architectures and finding bounded
counterexamples [122].
A security-path check requires a conservative execution or effect-flow projection. If every relevant
ingress-to-effect path intersects an enforcement cut, the structural model has no bypass of that cut. This
does not prove that the enforcement code authenticates correctly or that its policy predicate is correct. A
dependency graph or sampled service map is insufficient for a complete no-bypass claim.
75
Page 76
Extracted text for page 76
Reaktor: An Extensible Software Engine Technical preprint
When the requested property is assumed as a model fact, a successful run has not independently
established it. The property catalogue distinguishes modeling assumptions from assertions to be checked.
Incomplete observation-based graphs yield limited or unknown results for negative claims such as the
absence of an unauthorized path.
30.3 Constraint and temporal verification
SMT encodings support placement, capability, resource, and configuration constraints. A solver model
gives an assignment satisfying the encoded constraints; it does not establish resource availability in the
cloud. Unsatisfiable cores can explain conflicting requirements. Unknown or timed-out results remain
unknown. Z3’s supported theories and solver behavior provide a practical basis for such encodings [123].
TLA+ models describe concurrency, delivery, activation, and recovery [124]. Relevant invariants
include
□ Valid𝑠 (𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝐺𝑟𝑎 𝑝ℎ), (31)
□ ∀(𝑘, 𝑚) : 𝐶𝑜𝑚𝑚𝑖𝑡𝑡𝑒𝑑𝐸 𝑓 𝑓 𝑒𝑐𝑡𝑠(𝑘, 𝑚) ≤ 1 , (32)
□ a protected state commit uses an authorized epoch . (33)
Here (𝑘, 𝑚) identifies the deduplication/effect scope and message, not merely a transport sequence number.
These formulas require models of the commit mechanism and applicable effect boundaries.
A liveness objective can be written as
𝐴𝑐𝑐𝑒 𝑝𝑡𝑒𝑑 (𝑚) { 𝐶𝑜𝑚𝑚𝑖𝑡𝑡𝑒𝑑 (𝑚) ∨ 𝑅𝑒 𝑗 𝑒𝑐𝑡𝑒𝑑 (𝑚) ∨ 𝐷𝑒𝑎𝑑𝐿𝑒𝑡𝑡𝑒𝑟𝑒𝑑 (𝑚). (34)
It requires sufficient assumptions about fair scheduling, durable recovery, retries, and terminal handling.
Permanent loss of the required storage or execution capability cannot be excluded by graph connectivity.
Safety, liveness, fairness, abstraction, and bounded checking have distinct meanings [41].
30.4 Refinement and composition
For a logical protocol 𝐿 and physical realization 𝑃, a safety-oriented target is
Traces(𝑃) ↾obs ⊆ Traces(𝐿), (35)
with an explicit observation mapping and hiding of internal actions. Nonblocking and liveness preservation
need additional progress arguments; trace inclusion alone permits implementations that make too little
progress.
Component guarantees can be composed through assume–guarantee contracts. Assumptions include
the communication semantics and environment each component requires. Cyclic dependencies between
assumptions must be discharged rather than accepted because every component cites another’s guaran-
tee. Protocol duality and compatible schemas do not establish global deadlock freedom for arbitrary
compositions.
Supported lowering profiles should supply proof obligations or conformance suites for their mappings.
A local-to-remote transformation is valid only if the logical contract permits the resulting failure
and completion behavior. A dynamic update can intentionally change functionality; its obligation is
preservation of the surrounding required contracts and selected invariants, not unconditional equivalence
to all old behavior.
30.5 Simulation and implementation proofs
Deterministic test environments control clocks, random choices, delivery schedules, and storage failure
points where the runtime allows it. Scenarios include duplication, lost acknowledgements, delayed
76
Page 77
Extracted text for page 77
Reaktor: An Extensible Software Engine Technical preprint
callbacks, stale activations, partial migrations, and every crash cut in update publication. These tests
connect abstract counterexamples to implementation behavior but remain finite evidence.
Machine-checked proofs are most valuable for small foundational mechanisms: snapshot representation,
patch publication, boundary flattening, deduplication transactions, safe handle reclamation, and selected
controllers. Anvil demonstrates a concrete approach to verifying eventual reconciliation of Kubernetes
controller implementations [125]. Similar guarantees for Reaktor require an explicit implementation
model; no general controller correctness follows from adopting a graph registry.
The conditional propositions in this paper are small representation and protocol results. The complete
compiler, updater, and distributed runtime remain implementation-level proof obligations. A proof
assistant such as Lean can mechanize selected invariants once the relevant definitions stabilize [126].
30.6 Versioned evidence and invalidation
A verification record identifies the property, graph projection, source and contract revisions, policies,
compiler and adapter versions, model scope, assumptions, method, and supporting artifacts. Results
distinguish proved, exact-checked, bounded-checked, tested, observed, assumed, and unknown. The status
describes a specific claim, not the application as a whole.
Incremental invalidation tracks the dependencies of the analysis query, including negative facts and
global constraints. Adding a new edge can invalidate a previous “no path exists” result even if none of its
selected nodes changed. A cached certificate is reusable only when its full semantic dependency set and
trusted implementation versions remain valid.
Runtime monitors can test assumptions and detect violations. Absence of a violation in a monitored
interval does not prove an invariant for unobserved executions. Conversely, a verified abstract model does
not justify ignoring production evidence that an adapter assumption was false.
31 Constructing an assurance argument
A useful assurance argument connects a requirement to a model, an implementation boundary, a verification
method, and explicit assumptions. It is not a collection of green badges. This section develops that
connection through small examples and identifies the limits of each method.
31.1 From requirements to predicates
Consider the requirement “a notification retry must not send the same notification twice.” This statement
is incomplete. Does “send” mean enqueueing a request, acceptance by a provider, delivery to a device,
or presentation to a user? Are two devices separate destinations? How long may retries occur? Can an
operator intentionally replay a notification?
A more precise requirement might state that a particular consumer effect key (𝑔, 𝑚, 𝑑), identifying
subscription, message, and destination, has at most one committed provider submission receipt, within a
declared replay window, assuming the provider supports an idempotency key with the required semantics.
The requirement is now narrow enough to analyze. A different requirement, such as at-most-once user
presentation across devices, needs a different model and likely a different authority.
The graph should store the requirement’s scope, owner, and meaning, link it to the affected operation,
and identify its external assumptions. This follows the traceability discipline of systems engineering
rather than treating verification as an isolated CI task [127, 128].
31.2 Hoare-style local reasoning
A Hoare triple {𝑃} 𝐶 {𝑄} states that if precondition 𝑃 holds and command 𝐶 terminates normally, then
postcondition 𝑄 holds. Termination is a separate obligation in partial correctness. For a state migration,
77
Page 78
Extracted text for page 78
Reaktor: An Extensible Software Engine Technical preprint
𝑃 can include the old schema invariant and exclusive ownership; 𝑄 can include the new invariant and
preservation of selected business facts.
Suppose an old draft stores a single text field and the new schema stores text plus a default formatting
descriptor. A migration can preserve the text exactly and assign a defined default. A proof about this
record conversion does not establish that concurrent writers were paused or that a failed transaction is
recoverable. Those belong to the surrounding protocol.
IronFleet combines state-machine refinement with Hoare-style verification in practical distributed-
system implementations [129]. The relevant lesson is the layering: local implementation reasoning and
distributed protocol reasoning address different obligations and must agree on their interfaces.
31.3 Relational exploration with Alloy
Alloy is useful for discovering structural counterexamples. A model can represent nodes, owned ports,
edges, incidences, roles, and module exposure. The critical distinction is between a constraint assumed for
all candidate structures and an assertion being checked. Adding “all ports have valid owners” as a fact and
then checking that assertion says nothing about whether a mutation implementation preserves ownership.
A small structural experiment should instead describe the allowed patch relation and ask whether a
valid pre-state can reach an invalid post-state. For deletion, the counterexample may reveal an incidence
still pointing to a removed port. The fix can be rejecting the deletion, expanding it to include the relevant
incidence, or defining an explicit replacement mapping. The model helps choose the intended semantics
before the API hardens [122].
Scope is part of the result. A bounded search with a small number of entities can find a real logical
flaw but cannot establish arbitrary-size correctness without an additional argument. A property may also
be vacuously true because no model satisfying its assumptions exists. Check that meaningful executions
and counterexamples to deliberately weakened properties are representable.
31.4 State exploration with temporal models
A temporal model defines initial states, next-state actions, and the fairness assumptions used for progress
properties. TLA+ supports expressing these relationships directly [124]. A graph-patch model can include
readers proposing from a revision, a validator, a commit decision, conflicts, and retries. A LiveUpdate
model can include prepared generations, acquired views, publication, state transfer, and retirement.
For a safety property, exhaustively checking all reachable states of a finite model establishes that
property for that finite transition system. It does not establish that a different Kotlin implementation has
exactly those transitions. Model extraction, code generation, or implementation conformance connects
the two. For liveness, fairness must describe actual scheduling and recovery assumptions; declaring every
desired action fair can hide the very starvation or failure behavior under investigation.
A useful counterexample is a sequence of named actions linked back to graph entities and source
locations. Instead of reporting only “invariant violated,” the tool can show that a reader obtained an old
pointer, publication selected the new generation, reclamation freed the old generation, and the reader then
pinned the freed object. The sequence explains the missing atomicity boundary.
31.5 A reproduced finite generation model
The accompanying source package contains a standard-library Python state explorer, models/generat
ion_model.py. It enumerates a finite reference model of publication and reader acquisition. Prepared
generations are initially allocated, publication advances monotonically, readers can acquire or release, and
an inactive generation can be reclaimed when no reader pins it. The invariant is that the active generation
and every pinned generation remain allocated.
78
Page 79
Extracted text for page 79
Reaktor: An Extensible Software Engine Technical preprint
Two acquisition protocols are compared. The first acquires the current view and pins it in one modeled
atomic action. The second separates loading a pointer from pinning it. The second intentionally models
the unsafe lifetime protocol; it is not asserted to be present in the current Reaktor implementation.
Acquisition Readers Generations Reachable states Result
Atomic acquire/pin 1 2 7 Invariant holds in all explored states
Atomic acquire/pin 2 2 17 Invariant holds in all explored states
Atomic acquire/pin 3 3 169 Invariant holds in all explored states
Split load/pin 2 2 — Counterexample found; exploration
stops at first violation
Table 10: Results reproduced by the supplied finite reference-model explorer. These are model results, not runtime
benchmarks or end-to-end verification of Reaktor.
The safe runs examine respectively 11, 42, and 628 transitions, including transitions to already
discovered states. A combinatorial cross-check counts safe-model states as
𝐺−1 𝑎
∑︁ ∑︁ 𝑎
(𝑘 + 2) 𝑅 , (36)
𝑎=0 𝑘=0
𝑘
where 𝑎 is the active generation, 𝑘 the number of surviving earlier generations, 𝑅 the number of readers,
and 𝐺 the number of prepared generations. Each reader is idle or pins one of the 𝑘 + 1 allocated generations
that has been active. This expression yields the reported state counts for the selected scopes.
The unsafe run produces:
load(reader=0, generation=0)
publish(generation=1)
reclaim(generation=0)
pin(reader=0, generation=0)
The result illustrates why generation checks and reference counts must be embedded in a correct
acquisition protocol. It deliberately omits crashes, state migration, counter wrap, multiple update groups,
CPU memory reordering, and external resources. Those omissions are limitations of the checked model,
not claims that the omitted concerns are harmless. The script and machine-readable results are supplied
so that the finite claim can be reproduced and extended.
31.6 Abstraction and implementation conformance
Let 𝐶 be a concrete transition system and 𝐴 an abstract one. An abstraction 𝛼 maps concrete states
to abstract states. A simulation argument requires initial states to correspond and concrete steps to be
matched by appropriate abstract behavior, possibly including stuttering. If the abstract system never
reaches an unsafe state and the abstraction maps every relevant concrete failure to an abstract failure, the
concrete safety property follows under the simulation assumptions.
This last condition is essential. An abstraction that drops a native buffer lifetime cannot prove absence
of use-after-free in that buffer. An abstract queue that omits receipt expiry cannot establish deduplication
after arbitrary replay. An abstract authorization model that assumes authenticated subjects cannot prove
the correctness of the credential parser supplying them.
Reaktor should maintain a traceability chain from property to abstraction to lowering rule and
implementation artifact. Machine proofs can eventually establish selected links. Tests can exercise
conformance at boundaries. Unknown links remain explicit trust assumptions. seL4’s specification-to-
implementation verification illustrates the importance of a carefully stated proof boundary [130]; it does
not transfer kernel guarantees to arbitrary application code running above it.
79
Page 80
Extracted text for page 80
Reaktor: An Extensible Software Engine Technical preprint
31.7 Checking the transformation rather than trusting the optimizer
A compiler transformation can be accompanied by a small translation validator. For example, after
lowering a hyperedge to incidence records, a checker reconstructs its roles and endpoints and compares
them to the original. After constructing a deployment projection, a checker verifies that each omitted
external dependency has an explicit supported boundary stub. After an update plan is generated, a checker
verifies its expected-base revisions and compatible group mapping.
These checks do not prove arbitrary code generation correct. They narrow the trusted implementation
for specific structural transformations. A proof assistant can later establish the checker’s relation to
the formal property, or a verified compiler component can preserve the property by construction. The
incremental approach is to choose high-value, tractable obligations rather than begin with a claim to
verify every line of every backend.
31.8 Proof dependencies and invalidation
Evidence depends on more than the graph records directly mentioned in a property. An absence claim
depends on a complete query region. A protocol proof depends on its adapter semantics, scheduler
assumptions, and state-store behavior. A source-derived effect summary depends on the compiler, relevant
dependencies, and permitted escape hatches.
A verification certificate should therefore reference dependency queries, descriptor revisions, source
hashes, tool versions, assumptions, and completeness evidence. Adding a new ingress can invalidate a
no-bypass property even when the protected operation is unchanged. Changing a loader can invalidate
generation-isolation evidence even when the update manifest has the same fields.
An incremental verifier must recheck affected global predicates or conservatively invalidate them. It
should not use graph proximity as a universal proof-dependency rule. Proximity is a useful heuristic for
investigation; sound invalidation depends on the actual logical support of a claim.
31.9 Assurance economics and remaining judgment
Formal work is most valuable where it removes a repeated or high-consequence uncertainty. A small
structural validator can run on every edit. A bounded model can explore a difficult retry protocol before
implementation. A machine-checked theorem can protect a foundational kernel transformation used
by many applications. An expensive whole-system analysis may be justified only for a narrow critical
deployment.
AWS’s published experience demonstrates the practical use of formal specification and model checking
for difficult service-design problems [131]. Anvil shows a further step toward proving properties of real
cluster controllers [125]. These precedents support a layered verification strategy, not a claim that formal
methods eliminate requirements errors or replace operational testing.
The final acceptance decision still includes whether the modeled property is the right one, whether its
assumptions are credible, and whether the implementation’s environment satisfies them. Reaktor’s role is
to make those questions explicit, preserve their evidence, and prevent an unqualified “verified” label from
obscuring them.
32 Heterogeneous and cyber-physical systems
A heterogeneous robot is a useful stress test for the architecture because correct message schemas are
visibly insufficient. A camera, GPU perception process, local controller, mobile operator interface, cloud
planner, and firmware updater have different timing, ownership, and failure requirements. The system
graph must connect them without pretending that a UI refresh and a motor-control deadline have the same
semantics.
80
Page 81
Extracted text for page 81
Reaktor: An Extensible Software Engine Technical preprint
Operator / planner
bounded proposals
validated requests
Sensors Local controller Actuators
time, units, frames qualified constraints physical plant
local timing and safety boundary
Figure 9: A supervisory graph connects heterogeneous components without placing a cloud or agent round trip
inside the local control loop. Physical requirements remain attached to the relevant implementation and environment.
32.1 Typed physical quantities and coordinate frames
An endpoint carrying a distance should identify its unit and reference frame. A pose additionally requires
a frame convention, timestamp, and calibration context. A covariance matrix is useful only when its
ordering, units, frame, and uncertainty interpretation are defined. A bare array of floating-point values
hides these requirements.
A proposed measurement contract can therefore contain a schema for the value, a unit descriptor,
a frame identity, a producer clock, a time interval or uncertainty bound, and a calibration revision.
Converting between frames is an explicit transformation with a validity interval. The compiler can check
that a consumer requiring metres is not directly connected to a producer declaring millimetres, but it
cannot infer that a sensor is correctly calibrated from the unit annotation alone.
data class MeasurementDescriptor(
val valueSchema: DescriptorRef,
val unit: UnitRef,
val frame: FrameRef,
val clock: ClockRef,
val calibration: CalibrationRef,
val uncertainty: UncertaintyModelRef?,
)
These refinements belong to a robotics or physical-measurement dialect. They need not complicate a
string-valued application event. A common port substrate permits both while keeping the stronger checks
local to the domain that needs them.
32.2 ROS 2 as an integration boundary
ROS 2 supplies useful precedents for explicit communication quality and lifecycle. Its QoS model
distinguishes properties such as reliability, durability, history, deadline, lifespan, and liveliness, with
request/offered compatibility conditions [132]. Its managed-node design separates configuration, inactivity,
activation, and finalization so that external supervisors can control lifecycle [133].
A Reaktor adapter can import those declarations into endpoint requirements and observations. A
missed deadline becomes evidence about a declared expectation, not proof that a hard real-time guarantee
was provided. A reliability setting does not establish that an actuator command is safe or still relevant
when received. Application profiles must also specify freshness, cancellation, authority, and behavior
after communication loss.
The adapter should preserve native tooling and execution where they are already appropriate. Reaktor’s
workbench can connect ROS nodes to artifact versions, operator interfaces, calibration data, tests, and
deployment plans without replacing the robotics middleware or the local executor.
81
Page 82
Extracted text for page 82
Reaktor: An Extensible Software Engine Technical preprint
32.3 Discrete and continuous behavior
A hybrid model combines discrete modes with continuous state evolution. Let 𝑞 be a mode such as idle,
navigating, stopping, or faulted, and let 𝑥 describe continuous state such as position and velocity. Within
a mode,
𝑥¤ = 𝑓𝑞 (𝑥, 𝑢, 𝑤) (37)
models dynamics under control 𝑢 and disturbance 𝑤. Guards permit discrete transitions, and reset maps
describe state changes at those transitions. Hybrid-automata research provides a formal framework for
such combinations and carefully identifies decidable subclasses [134, 135].
A Reaktor behavioral model can reference this dynamics model and connect its inputs to sensor and
actuator ports. It does not follow that an arbitrary hybrid system becomes decidable or accurately modeled.
Calibration, physical uncertainty, delays, and unmodeled effects remain assumptions or measured evidence.
For an illustrative one-dimensional stopping argument, suppose speed does not exceed 𝑣 ≥ 0 during the
reaction interval, total reaction delay is bounded by 𝜏, and braking deceleration is at least 𝑎 𝑚𝑖𝑛 > 0 after
the delay. Under those simplified assumptions, distance before stopping is bounded by
𝑣2
𝑑 𝑠𝑡𝑜 𝑝 ≤ 𝑣𝜏 + . (38)
2𝑎 𝑚𝑖𝑛
The first term accounts for motion during delay; the second follows from constant-deceleration kinematics
using the conservative lower bound. A real safety envelope must additionally account for sensing error,
obstacles, traction, slope, actuation limits, and the validity of the delay and deceleration assumptions.
This equation is an explanatory model, not a certified robot controller.
The graph makes the dependencies of that envelope explicit: a transport change affects 𝜏; a firmware
change can affect actuation; a calibration change affects measurement uncertainty. A software update that
preserves a message type can still invalidate the physical argument.
32.4 Control barriers and qualified safety boundaries
For a simplified smooth control-affine model, a safe set can be described by ℎ(𝑥) ≥ 0. Under the
hypotheses of a control-barrier-function construction, a constraint of the form
𝐿 𝑓 ℎ(𝑥) + 𝐿 𝑔 ℎ(𝑥)𝑢 + 𝛼(ℎ(𝑥)) ≥ 0 (39)
can support forward invariance. Here 𝐿 𝑓 ℎ = ∇ℎT 𝑓 and 𝐿 𝑔 ℎ = ∇ℎT 𝑔 describe how ℎ changes along
the dynamics, and 𝛼 is an increasing function with 𝛼(0) = 0, chosen according to the theorem’s
conditions [136]. This is a meaningful connection between a local control mechanism and an explicit
property.
The sampled implementation needs its own treatment of delay, discretization, numerical error, relative
degree, disturbances, and actuator limits. The displayed continuous-time inequality alone does not verify
a deployed controller. Reaktor can track the relevant model, implementation, bounds, and evidence as
linked artifacts and reject updates that invalidate an adopted requirement.
The safety controller should remain local and separately authorized where required by the system’s
safety case. Cloud planners, language-model agents, operator UIs, and dynamically updated feature code
provide proposals or bounded requests rather than unrestricted actuator access. Their failure must not
remove the qualified protection. A software framework is not a substitute for hazard analysis, hardware
interlocks, testing, or the applicable certification process.
32.5 Feedback, observability, and supervisory control
In control theory, observability concerns recovering internal state from measured outputs under a model;
it is not identical to software telemetry. Feedback Systems explains this distinction and the conditions for
82
Page 83
Extracted text for page 83
Reaktor: An Extensible Software Engine Technical preprint
control and estimation [137]. A trace dashboard can show every command yet omit a physical variable
necessary for safe control. Conversely, a local controller can have sufficient state estimation without
exporting every sample to a central service.
Reaktor should represent which sensors and estimators support a control claim and which observations
merely assist operators. A supervisory graph can monitor health, select validated modes, and coordinate
maintenance. It should not add a remote round trip to a hard real-time loop just to centralize management.
32.6 Updates in physical systems
A dynamically supported UI or planning subgraph may update while the machine continues operating.
A control or calibration change can require a stationary, de-energized, or otherwise certified safe mode.
Update eligibility must therefore include a physical safe-point condition issued by the appropriate local
authority, not merely an empty message queue.
After activation, the system should verify that the selected artifact, parameter set, calibration, and
controller mode form an approved configuration. A rollback to old code may be invalid if hardware
configuration or calibration has changed. The same release-mapping discipline used for Hermes applies,
with additional physical constraints and a narrower trusted boundary.
32.7 Energy and resource constraints
Battery-powered devices have
∫ an energy budget as well as CPU and memory budgets. Over an interval,
consumed energy is 𝐸 = 𝑃(𝑡) 𝑑𝑡. This elementary relation can connect measured processing and
communication power to mission planning, but workload variation and hardware states must be included
before making a useful prediction. A perception update that increases computation may improve accuracy
while reducing operating duration or causing thermal throttling.
The graph should expose these tradeoffs as model inputs and observations rather than a single
“performance” score. Timing, power, accuracy, and safety can conflict. A planner may choose among
already qualified configurations; inventing a configuration is a separate engineering and validation task.
32.8 An interactive validation laboratory
The Reaktor Arena proposal uses a standalone Unreal project to make decision policies, actor-owned state,
event traces, and scenario replay visible before attempting a Reaktor runtime bridge [138]. Its intended
loop is to run a scenario, inspect a selected agent, change a rule or weight, and compare a replay. This
is useful for teaching and for exposing assumptions in a policy or protocol. A future bridge can keep
high-level orchestration in Reaktor while Unreal owns frame-level simulation.
The distinction between a laboratory and a deployment remains essential. A simulated intervention is
not evidence that a robot’s physical plant, sensor calibration, network, or emergency mechanism satisfies
the model. Arena can produce test cases and counterexamples; it does not replace field validation or
qualified safety engineering.
33 Application and adoption studies
The following studies are constructed architectural scenarios, not reports of deployed Reaktor customers
or measured productivity improvements. They test whether the same primitives remain useful under
different organizational and technical constraints. Each scenario starts from the problem, identifies the
smallest useful Reaktor adoption, follows a change or failure, and states where the framework’s costs may
exceed its benefits.
83
Page 84
Extracted text for page 84
Reaktor: An Extensible Software Engine Technical preprint
33.1 A solo developer: an offline field-notes application
Problem and minimum system. A solo developer builds a mobile application for collecting notes and
photographs during field work. The application should open quickly, work without connectivity, preserve
drafts, and synchronize selected records later. The initial system contains a UI, a local SQLite-backed
store, an optional synchronization endpoint, and an object-upload operation. It does not need Kubernetes,
a graph database, distributed actors, or an always-running central registry.
The graph can be authored in ordinary Kotlin. A note screen owns a state-observer port and a
save-command port. A repository owns the state authority for local drafts. An upload client exposes
a typed call whose result distinguishes durable server acceptance from a transient network failure. A
lightweight development tool reads the in-process manifest and navigates from a screen to its repository
and tests.
Local-first research provides a useful precedent for separating responsive local work and data ownership
from permanent dependence on a cloud service [139]. Reaktor does not have to mandate a fully peer-to-
peer model: this application can begin with one local authority and an explicit server synchronization
policy.
Building and running. The developer first implements storage and the screen without synchronization.
A fake upload endpoint supports tests. Later, the same contract is bound to an HTTP implementation.
The graph records which operations require connectivity, while the UI uses local state and displays the
status of pending synchronization. A failed upload does not delete the local photograph or pretend that a
server copy exists.
Suppose the application is terminated after the server accepts an upload but before the local receipt is
stored. Recovery uses the operation’s stable identity to resolve or repeat the upload under its idempotency
contract. The graph does not solve this automatically; it makes the recovery obligation visible and provides
a reusable profile and test harness for it.
A feature update. A new form layout can be delivered through a supported Hermes region only if the
installed host already exposes the necessary UI and storage contracts and the distribution policy allows the
channel. A request for a previously unavailable native sensor requires a host release. The update planner
should explain that difference directly.
Benefits and limits. The main benefits are typed navigation, local testability, explicit offline states, and
a migration path that does not require replacing the application structure. The solo developer should not
have to maintain a separate graph document or deploy an infrastructure service to obtain these benefits.
If the graph DSL creates more ceremony than the few modules justify, ordinary interfaces and a small
native project can be the better choice. The adoption criterion is reduced repeated integration work, not
completeness of the workbench feature list.
33.2 An early-stage startup: messaging, engagement, and analytics
Problem. A startup adds chat, groups, notifications, and engagement analysis to a product used through
several clients. BestBuds supplies the motivating shared-interface and actor patterns, but the full pipeline
below is a proposed realization rather than a claim about every current implementation detail [10].
The smallest useful production graph has a typed messaging API, an authorization boundary, a
transactional message authority, realtime delivery, and an asynchronous publication for downstream
effects. The same declaration can be realized as an in-process integration test and as an app/edge/server
deployment. A shared interface makes the caller and server agree on operation shape; deployed-version
checks handle old installed clients.
84
Page 85
Extracted text for page 85
Reaktor: An Extensible Software Engine Technical preprint
A message across the graph. The client creates a provisional message identity and updates local UI
state. The authoritative send operation validates membership, commits the message and outbox record,
and returns a durable identity. The outbox relay publishes a committed event. A realtime subscription
updates the conversation; a notification subscription requests push delivery; an analytics subscription
advances a projection. The publication is one logical multi-party relationship, while each subscription
has its own delivery and effect scope.
A retry after an ambiguous timeout uses the same operation identity. A duplicate event cannot be
assumed harmless merely because its schema is valid. Each consumer applies its own idempotency or
deduplication contract. A failed analytics consumer should not undo the committed message, and a
successful message commit should not imply that every projection is current.
Operational investigation. An operator observes that the message list is current but engagement
analytics is stale. The graph view follows the message dataset to the publication and then the analytical
projection, showing its last applied checkpoint, recent rejection evidence, and deployed consumer schema.
A useful result identifies whether the consumer is absent, failing, lagging, or processing an unexpected
schema. A central “service healthy” indicator cannot make these distinctions.
Evolution. Adding a new message variant changes the shared contract, persistence schema, renderers,
and selected consumers. The impact query identifies deployed readers that cannot understand it. A
compatibility rollout can first introduce tolerant readers and storage support, then producers, then removal
of old handling after the adoption window. A Hermes feature update changes compatible presentation
logic; it does not silently alter the server’s data authority or grant new permissions.
Benefits and limits. This scenario offers repeated opportunities to reuse protocol, state, schema-
evolution, and update mechanisms. It also exposes the risk of premature distribution. If one process and
one database meet the workload, Reaktor should compile that realization rather than encourage a service
per graph node. A startup gains little from an elegant graph if maintaining its infrastructure prevents
product development.
33.3 A software agency or B2B vendor: families of related applications
Problem. A team delivers applications with a common operational core and customer-specific workflows,
branding, data retention, and integrations. Copying an entire repository for each customer makes later
security and schema changes difficult to propagate. A single universal configuration file can become
equally difficult to reason about when incompatible variants are combined without constraints.
A Reaktor product family can use parameterized modules with explicit required and optional interfaces.
A shared order module exposes typed operations. Customer modules supply approved authentication,
invoicing, storage, and workflow bindings. Visual themes and feature selections are data where appropriate;
genuinely different behavior remains an explicit implementation variant.
A product-line configuration. Let a configuration select an invoicing backend, approval workflow, data
region, and notification profile. Constraints reject invalid combinations, such as a workflow that requires
a capability absent from the selected backend. Product-line feature models provide an established way to
analyze such selections; their satisfiability does not establish the behavior of each implementation [140].
An instantiated graph carries a customer scope. A stable module identity is distinct from a customer’s
dataset identity. Sharing an implementation does not authorize sharing runtime state. Tenant isolation
applies to every relevant read, write, cache key, message, and operational command, not only the UI’s
initial login.
85
Page 86
Extracted text for page 86
Reaktor: An Extensible Software Engine Technical preprint
A shared update. The team fixes a schema-conversion defect in the shared module. The dependency
query finds affected configurations and their deployed artifacts. Each configuration runs the relevant
conformance suite and checks its own host compatibility and state policy. Customers with compatible
dynamic boundaries may activate through LiveUpdate; others receive a conventional application or server
release.
A customer-specific migration can prevent rollback even when the shared code artifact is older and still
available. Release records must therefore map code, schema, configuration, and customer state policy
rather than offer one indiscriminate “revert module” action.
Human and agent work. An engineer designs and proves a new integration mechanism once. Agents
can then instantiate approved configurations, generate routine screens, and update source declarations
under the product-line constraints. A novel customer requirement that falls outside the module’s contract
should be surfaced as an extension task, not squeezed into an opaque escape hatch merely to finish
generation.
Benefits and limits. The reusable unit becomes a supported module with tested variation points, not a
folder of copied files. This is valuable when products share stable semantics. If every customer requires
unrelated behavior, an elaborate configuration system can become harder to maintain than independent
products. A family model should remain a hypothesis about actual reuse and be refactored when that
hypothesis fails.
33.3.1 Nexergy as a concrete composition target
The Nexergy design documents specify a B2B trader-aggregator platform with buyer, operations, supplier,
warehouse, logistics, and finance surfaces. They explicitly assume the necessary Reaktor capabilities are
available; they are product designs, not reports of a completed deployment [141, 142].
Their useful contribution is the distinction between reusable mechanisms and a particular business.
Inventory reservation, monetary posting, fulfillment transitions, notification delivery, and audited approval
are candidates for reusable systems. Biomass grades, supplier-disclosure policy, quote thresholds, and
operating sequences belong to Nexergy’s product composition. A new vertical is not a reason to create a
framework module named after that vertical.
A quote-acceptance feature can connect typed commands to a reservation mechanism, an approval
policy, an order transition, a ledger posting, and downstream notifications. Product authors select and
configure those relationships. Engineers implement the hard reservation and posting invariants, adapter
contracts, and recovery behavior. The visual and source views should show where application-specific
logic remains necessary rather than calling the entire business “wiring.”
The two source designs propose different package decompositions: one emphasizes commerce,
inventory, logistics, and ledger modules; the other factors catalog, ledger, and fulfillment with thin
audit/compliance primitives. This specification preserves them as alternatives, not a combined mandatory
taxonomy. Their common architectural lesson is that a small tested mechanism can participate in many
product recipes; choosing the best package boundary requires implementation and usage evidence.
33.4 A growing commerce platform: checkout under partial failure
Problem. A commerce system coordinates carts, inventory reservations, payment authorization,
fulfillment, and customer communication. The graph should expose the workflow and its effects without
claiming that all services share one atomic transaction.
The checkout contract returns outcomes such as confirmed, rejected, pending resolution, or requiring
customer action. A durable workflow coordinates state transitions. Inventory and payment operations
86
Page 87
Extracted text for page 87
Reaktor: An Extensible Software Engine Technical preprint
have distinct identities and authorities. A payment timeout is an unknown outcome until reconciled under
the provider’s contract; it is not grounds for automatically issuing an unrelated charge.
A proposed execution. The workflow validates the cart, reserves inventory, requests payment authoriza-
tion with a stable idempotency key, and records the result before scheduling fulfillment. Each step has
a declared retry rule and persisted progress. If payment succeeds but an inventory reservation expires,
recovery follows the business policy for re-reservation, cancellation, or compensation. Compensation is a
new effect that can itself fail; it is not erasure of history.
An internal graph may use a join when both an inventory condition and a payment condition are
required. The join’s enablement predicate matters. A reachability view showing paths from both services
to fulfillment does not prove that fulfillment waits for both. The protocol model and its implementation
establish that condition.
Verification. A useful invariant states that fulfillment cannot be committed without the required
authoritative conditions, within their validity windows. A separate invariant restricts duplicate payment
effects to the guarantees actually provided by the payment interface. A liveness claim needs assumptions
about eventual reconciliation and the availability of a terminal business outcome. Permanent provider
failure may leave an explicit manual-resolution state rather than an automatic success.
Deployment and updates. A rule-engine UI may be dynamically updated while the transactional
authority remains native or server-deployed. A workflow definition update must specify how existing
workflow executions continue: pin their definition, migrate at an approved point, or finish under the old
implementation. Routing every existing execution into the newest definition can invalidate its recorded
decisions.
Benefits and limits. Reaktor’s benefit is a coherent view of effects, versions, business states, tests,
and evidence. Mature payment, database, and workflow systems remain backends. Reaktor is not a
reason to replace a proven ledger or invent a new distributed transaction protocol. Where an existing
orchestration platform already provides adequate visibility and assurance, integrating it read-only may be
more economical than adopting a new executable layer.
33.5 A large corporation: federating a brownfield estate
Problem. An organization operates services written in several languages, a few legacy databases,
independent deployment teams, multiple cloud providers, and specialized operational tools. Requiring
a rewrite would make adoption implausible. The initial goal is reliable navigation and impact analysis
across existing authorities, not universal execution through Reaktor.
Source scanners, schema importers, infrastructure configuration, service catalogues, and runtime
observations contribute separate graph fragments. A legacy service can initially be source-linked and
observation-only. A typed wrapper can later expose supported calls. A team can adopt native graph
declarations for new modules without changing unrelated systems.
Authority and organizational boundaries. Each team owns its declarations and operational approvals.
A central registry may cache metadata and summaries but should not gain unrestricted write authority
over every backend. A project-level source of truth can remain federated across repositories and systems.
An alias linking an observed service to a source module needs evidence, especially when deployment
names are reused across regions or tenants.
A higher-level view can show that several applications depend on a particular dataset while leaving
sensitive record contents in the owning store. Access-filtered projections should preserve enough
87
Page 88
Extracted text for page 88
Reaktor: An Extensible Software Engine Technical preprint
completeness information to avoid misleading conclusions. A user who cannot see a restricted dependency
should not receive a false universal claim that no such dependency exists.
A migration. A team plans to replace an old billing endpoint with a new implementation. The
graph identifies declared callers, generated clients, observed traffic, relevant schemas, tests, deployment
operations, and unknown call paths. The organization first wraps the old endpoint, establishes conformance
tests, compares results under controlled traffic, and shifts approved callers. Observations support the
migration, but sampled absence of traffic alone is insufficient evidence to delete the old service.
Incident response. An operator begins from a failed business operation and follows its resource
and dependency view. A deployment artifact, policy revision, and data projection may have changed
independently. The system query returns their source watermarks rather than inventing a globally
simultaneous state. The operator can prepare a targeted action and obtain the owning team’s approval
with a traceable plan and receipt.
Benefits and limits. Federation can reduce repeated architecture reconstruction and make uncertainty
visible. Its costs include importer maintenance, identity reconciliation, metadata access policy, and
organizational agreement about authority. A confidently wrong graph is worse than an explicitly incomplete
one. Adoption should therefore progress from read-only navigation and high-value queries to carefully
scoped operations. The graph cannot compensate for missing ownership or grant a central team authority
that the organization has not established.
33.6 A platform team: operating shared cloud and data services
Problem. A platform team provides a deployment environment, standard observability, databases,
queues, and release workflows for several application teams. Each application should use approved
capabilities without reproducing infrastructure internals. The system must also support safe exceptions
and expose where a service’s declared requirements are not currently met.
The platform publishes modules that describe resource contracts and operational interfaces. An
application requests a durable event channel, a transactional store, and an observation profile. The
deployment planner binds them to approved backends and failure domains. A resource’s desired declaration
remains distinct from its provider-observed state.
Reconciliation. A controller repeatedly compares desired and observed state and performs permitted
actions. It must tolerate duplicate observations, retries, stale reads, and partially completed operations.
Anvil’s verification of cluster-controller liveness is a relevant precedent for treating this loop as a precise
protocol [125]. Reaktor should select a small controller interface with tractable obligations rather than
assume that a generic cloud SDK automatically yields a correct reconciler.
A successful create request is followed by observation of the resulting resource, not immediately
relabeled as a healthy deployment. A failed reconciliation reports whether it lacks permission, capacity,
compatible configuration, or sufficiently fresh evidence. Application teams can inspect these findings
without receiving the credentials that permit arbitrary infrastructure mutation.
A platform capability extension. The team adds a new analytical-store backend. Its package contains
schemas, connectivity, lifecycle, deployment support, lineage integration, cost-model assumptions, and
conformance evidence. Applications already depending on the supported analytical contract can opt
into the new realization. Those requiring unsupported query or consistency semantics remain on the old
backend or need an explicit adapter.
88
Page 89
Extracted text for page 89
Reaktor: An Extensible Software Engine Technical preprint
Benefits and limits. The value lies in reusable, governed interfaces and traceable operations. Existing
Pulumi, Kubernetes, cloud APIs, and database management remain implementation systems. Reaktor
should not become an additional authoritative configuration layer that competes with them. If the
platform already has coherent contracts and excellent operational integration, Reaktor must demonstrate
an incremental benefit rather than merely aggregate the same dashboards.
33.7 A robotics organization: a mixed-runtime fleet
Problem. A fleet combines embedded controllers, native perception processes, accelerators, local oper-
ator applications, intermittent networks, and centralized planning. The organization needs configuration
traceability and repeatable software deployment while preserving local timing and safety requirements.
Section 32 defines the relevant physical-model constraints.
The system graph describes sensor contracts, transforms, perception stages, planner interfaces, actuator
authority, and the independent safety boundary. It connects code artifacts to calibration revisions and
device classes. Runtime observations include freshness, missed expectations, health, and progress; bulk
sensor data remains in suitable storage or streaming systems rather than being copied into the architecture
registry.
Two control timescales. A local qualified controller enforces the required actuator limits and stopping
behavior. A fleet planner assigns tasks and routes at a slower timescale. An operator UI inspects state and
requests permitted changes. A language-model agent can assist with diagnostics, plan explanations, and
code development; it does not receive an unrestricted actuator port merely because the graph contains one.
When connectivity is lost, local behavior follows an explicit policy. A robot may finish an already
approved bounded action, enter a safe mode, or await local intervention. A cloud planner cannot promise
immediate remote revocation across a partition. The policy must state what authority remains valid offline
and for how long.
A perception update. A new model artifact changes accuracy, memory demand, and processing time.
The update planner checks the device’s runtime capabilities, model input/output schema, calibration
assumptions, resource envelope, and required tests. If the change affects a control assumption, deployment
requires renewed evidence or a restricted operating mode. Type compatibility alone cannot authorize the
update.
An operator-interface update may be eligible for next-entry Hermes activation. A control-loop update
may require a stopped machine and a different validated release process. Both are graph-region updates,
but their activation authorities and evidence differ sharply.
Benefits and limits. Reaktor can connect tools and records that otherwise make fleet diagnosis difficult:
which machine runs which artifact, with which calibration, under which contract and safety envelope.
It should not replace a qualified real-time runtime or claim certification through a graph model. For
small embedded firmware with a fixed schedule and severe memory limits, a generated static manifest for
inspection may be the only appropriate Reaktor footprint.
33.8 A research or machine-learning team: reproducible pipelines
Problem. A team combines data acquisition, preprocessing, training, evaluation, inference services,
and human review. The pipeline spans local workstations, GPU nodes, object storage, and deployment
targets. It needs reproducibility and lineage without assuming that every numerical execution is bitwise
deterministic.
The graph contains dataset and schema identities, transformation definitions, artifact dependencies,
environment descriptors, and evidence from specific runs. Tensor or image contents remain data. A
89
Page 90
Extracted text for page 90
Reaktor: An Extensible Software Engine Technical preprint
training graph is a specialized computational object linked to the broader system graph, not an excuse to
represent each numerical element as an architectural node. TensorFlow’s use of dataflow graphs across
heterogeneous devices is a relevant precedent for this distinction [143].
Building and running. A researcher implements a new preprocessing step and supplies its input/output
contract, parameter schema, and tests. The graph identifies affected datasets and downstream evaluation
jobs. A run records the input snapshot, code artifact, configuration, toolchain, and outputs. A failed run
does not mark a dataset’s newest declared version as successfully materialized.
When an inference model is promoted, a release binds its artifact to a schema, serving implementation,
resource requirements, and evaluation evidence. An endpoint compatibility check establishes that clients
can exchange data; domain evaluation establishes whether the predictions are acceptable. These are
different acceptance criteria.
Human and agent contributions. Agents can prepare pipeline changes, reproduce failures, and compare
configurations under a bounded experiment budget. Humans can define the scientific question, identify
leakage or invalid evaluation, and invent a new analysis mechanism. Once adopted, that mechanism
becomes a reusable module with provenance and explicit limitations rather than a notebook fragment
whose assumptions must be reconstructed later.
Benefits and limits. The benefit is connected provenance, testability, and deployable contracts. A
specialized numerical framework remains responsible for optimized kernels and distributed training.
Reaktor should wrap and inspect it rather than insert a generic graph interpreter into every tensor operation.
Exploratory research can also require unstructured freedom; demanding a complete deployment and
assurance model before a first experiment would be counterproductive.
33.9 CompanyOS: browser operations and human handoff
CompanyOS provides a source-reported migration example beyond a Kotlin mobile application. Its
documentation records a TypeScript/Vite frontend, shared operation identities, Worker routing, a Durable
Object-backed browser-session path, and a workflow planner with explicit human gates. A local
headed-Playwright path permits operator handoff rather than treating every browser interaction as
autonomous [144]. These are reported slices; the complete system-graph integration remains a target of
this specification.
The proposed Reaktor representation contains a portal-session component, workflow definition,
individual workflow run, browser instance, protected credential reference, evidence artifact, and human
approval task. Their interfaces are different. A workflow step can request preparation of a form, while an
approval step requires an authorized person to inspect and accept a specific result. Resuming a workflow
must bind the approval to that result and revision, not to a generic Boolean remembered from an earlier
attempt.
This case makes the difference between a function call and a long-lived operation concrete. The
browser can disconnect; a portal can change; an external action can have an uncertain outcome. A retry
cannot blindly repeat a submission. Recovery may require inspecting the external system and recording a
reconciliation decision. A screenshot can support review, but is not a database commit receipt.
The human gate is an intentional part of the product. The graph describes where automated preparation
stops, what evidence is available, and which authority resumes the operation. It does not make CAPTCHA
solving, credential collection, or signature submission implicit capabilities. Sensitive interactions remain
with the authorized operator, and secret values do not enter ordinary graph context.
Reaktor’s potential benefit is a common representation connecting workflow state, local/cloud browser
realizations, typed operations, and evidence. A simple one-off script may not justify that machinery.
90
Page 91
Extracted text for page 91
Reaktor: An Extensible Software Engine Technical preprint
The case becomes persuasive when the organization repeatedly operates many stateful workflows whose
recovery, audit, and human handoff would otherwise be implemented separately.
33.10 Where adoption should be rejected or reduced
A one-off script, a static website, or a small application with few external dependencies may not recover
the cost of a new abstraction layer. A high-performance library can expose a small integration boundary
without adopting Reaktor internally. A proven system with adequate tooling may gain only marginal
benefit from another registry. Safety-certified firmware may permit metadata export while excluding
dynamic code or general-purpose runtimes entirely.
The relevant question is not whether a system can be drawn as a graph. Almost any system can. The
question is whether explicit, maintained cross-system contracts improve a recurring engineering task
enough to justify their storage, elaboration, runtime, and governance costs.
A useful cost model compares expected avoided integration, incident, and change effort against adoption,
migration, importer maintenance, and operational overhead. Its parameters must be measured locally. A
feature-rich workbench does not establish positive return on investment. Adoption can also be partial:
shared service interfaces first, then structural validation, then lineage, then selected operational or agent
capabilities.
Setting Smallest useful footprint Warning sign
Solo application In-process graph, contracts, local tests A central infrastructure service is
required merely to run the app
Product startup Shared APIs, state/effect profiles, Node count is mistaken for a reason to
deployment projection create more services
Application family Parameterized modules and variation Configuration becomes a disguised
constraints untyped programming language
Enterprise estate Read-only federation and source-linked Incomplete discovery is presented as
impact queries complete authority
Robotics fleet Metadata, typed integration, qualified Remote or dynamic tooling enters an
local boundaries unqualified safety loop
Scientific workflow Artifact and dataset lineage, Every experiment requires premature
reproducible run records production formalization
Table 11: Adoption should follow repeated engineering needs, not an obligation to enable every subsystem.
34 Industrial precedents and their limits
The proposed architecture combines mechanisms that have been developed in different technical commu-
nities. A precedent establishes that a particular mechanism is useful under particular conditions; it does
not establish the performance, usability, or commercial value of their integration in Reaktor. Table 12
separates the transferable mechanism from the inference that must still be tested.
34.1 The engine precedent and its different mechanisms
Section 2 develops the Blueprint authoring relationship. The complementary engine precedents concern
execution planning, storage, asset lifetime, and relevance filtering. They validate different constituent
mechanisms; none supplies a proof that all of them can be combined at negligible cost in a distributed
application.
91
Page 92
Extracted text for page 92
Reaktor: An Extensible Software Engine Technical preprint
Precedent Transferable mechanism Boundary of the comparison
Unreal Engine Shared descriptions, domain-specific A distributed product is not one game loop
editors, dependency-aware execution, or one render graph
runtime inspection
MLIR and Typed intermediate forms, staged A valid intermediate form is not proof of
compilers lowering, verification passes an arbitrary backend
Service Weaver and Component contracts and explicit Supported failure semantics and runtime
Hydro deployment/communication decisions assumptions differ
Backstage and Ownership, discoverability, provenance, Catalog metadata is not a complete
OpenLineage execution-linked relationships executable specification
FoundationDB A narrow substrate, layered functionality, Testing does not become proof merely
deterministic fault simulation because it is deterministic
Verified systems Explicit trusted boundaries and Each theorem is specific to its model,
implementation-linked specifications implementation and assumptions
Table 12: Precedents support constituent mechanisms rather than an end-to-end validation of Reaktor.
34.2 Render graphs: declare, validate, compile, execute
Unreal’s Render Dependency Graph records passes and resource use during setup, compiles the resulting
dependencies, and executes a planned workload. Dependency knowledge supports scheduling and
resource-lifetime decisions [101]. Reaktor applies the same separation to graph snapshots and execution
plans: expensive structural analysis belongs before routine invocation, while the runtime uses prepared
bindings.
The analogy has limits. A render graph commonly describes a bounded workload with declared
resources. A running distributed application includes requests that have not arrived, actors that have not
activated, network partitions, and external effects. Reaktor therefore distinguishes a structural graph from
a particular execution graph. It can compile a local pure-dataflow fragment aggressively without treating
the entire product as an acyclic render schedule. Undeclared effects invalidate optimizations in either
setting; an opaque component requires a conservative effect boundary.
34.3 MassEntity: data layout follows processing
MassEntity separates data fragments from the processors operating on entities, organizing related data for
processing rather than requiring each entity to carry an object-oriented behavior hierarchy [100]. The
lesson for Reaktor is the separation between semantic identities and physical representation. A graph
node can be represented by an indexed row, while execution behavior resides in a binding registry.
Copying the entire archetype mechanism would be less justified. An application knowledge graph may
accumulate many sparse annotations with independently changing lifetimes. Grouping every combination
into a new archetype can produce fragmentation and migration overhead. Reaktor uses dense tables for
frequently traversed structural fields and sparse side stores for infrequent aspects; the final layout remains
a measured implementation choice.
34.4 Asset management, replication, and gameplay mechanisms
Unreal’s Asset Manager distinguishes primary assets and their dependencies and connects identification
to loading, cooking, and chunking [13]. Reaktor’s artifact graph similarly links stable semantic entities to
content-addressed build outputs and deployment requirements. A logical identifier is not a file offset or a
loaded object address. Asset dependency information can guide update packaging, but does not by itself
prove that an old runtime generation can be unloaded.
92
Page 93
Extracted text for page 93
Reaktor: An Extensible Software Engine Technical preprint
Unreal’s Replication Graph organizes actors into structures used to determine relevant replication work
and reuse information across connections [145]. This supports Reaktor’s use of indexed, incremental
projections rather than repeatedly scanning the full system for every client or observer. Relevance filtering
is not authorization: a fast selection structure must still operate within the principal’s permitted scope.
Nor does a game replication policy establish a durable messaging guarantee.
The Gameplay Ability System packages reusable abilities, effects, attributes, and asynchronous
tasks [15]. Its relevance is that a difficult mechanism becomes a reusable unit with a lifecycle and
integration points. Reaktor extensions should have the same completeness: a new primitive needs
initialization, cancellation, state ownership, failure reporting, testing, and inspection. A callable function
plus an icon is not an engine-level mechanism.
34.5 Compiler infrastructures and reproducible construction
MLIR supports multiple intermediate representations and extensible dialects connected by progressive
lowering [51]. Reaktor’s structural, behavior, data, and deployment dialects should likewise have explicit
legality rules and conversion boundaries. A robotic timing constraint does not belong in the same
unrestricted record as an arbitrary UI label merely because both can be serialized. Dialects share identities
and infrastructure while retaining their semantics.
Bazel’s account of hermeticity and Nix’s functional deployment model motivate explicit build inputs
and reproducible artifact identities [75, 76]. For Reaktor, an artifact should be traceable to source,
compiler, dependencies, configuration, and generated bindings. A hash proves identity of bytes, not their
correctness or reproducibility. An undeclared network fetch during compilation breaks the declared build
model even if the final artifact has a hash. Providers should expose such limitations rather than hide them
behind a successful build status.
CompCert illustrates another useful separation: semantic-preservation results are attached to particular
compilation stages and source/target semantics [146]. A Reaktor lowering pass should state what it
preserves, including which failures and effects are observable. Merely using a verified compiler for some
generated code would not verify the graph elaborator, external adapters, or deployment process.
34.6 Distributed programming and operational services
Service Weaver provides a precedent for common component interfaces with separately chosen deployment
structure; Hydro provides a precedent for making locations and communication part of the programming
abstraction [69, 70]. Reaktor retains shared interfaces while requiring each realization to preserve declared
protocol requirements. It does not treat arbitrary local references as automatically distributable.
At a different scale, Meta’s ServiceRouter describes an operational service-routing architecture [147].
Its relevance is that routing is a substantial runtime subsystem involving discovery, policy, efficiency,
and failure handling, not a cosmetic property of a drawn edge. Reaktor can model or integrate such a
subsystem rather than implement a competing hyperscale router for every deployment. A common graph
vocabulary should reduce integration work, not erase the benefits of mature specialized execution systems.
Zanzibar connects authorization decisions to a consistent relationship model [148]. Reaktor can
describe permission dependencies and their enforcement points, but an ownership label in a catalog is not
a grant, and a stale relationship observation is not sufficient authority for a protected action. Spanner
demonstrates the role of explicit time assumptions and synchronization mechanisms in strong distributed
guarantees [57]; labeling a graph edge “consistent” supplies none of those mechanisms.
34.7 Application building blocks and operational composition
Dapr exposes building blocks for distributed applications, including invocation, state, messaging, and
actors [149]. Expo provides an integrated mobile toolchain and explicitly compatible update runtimes [108].
93
Page 94
Extracted text for page 94
Reaktor: An Extensible Software Engine Technical preprint
These are useful neighboring abstractions, not deficient versions of Reaktor. Reaktor’s proposed distinction
is the connection of reusable application mechanisms to a typed authoring graph, source representation,
execution profiles, and operational evidence. Whether that connection improves completed work enough
to justify another framework must be tested against these competent alternatives.
34.8 Catalogs, lineage, and provenance
Backstage’s software catalog uses source-managed metadata to make components and organizational
ownership discoverable. Its relation documentation explicitly distinguishes organizational ownership from
runtime authorization [150]. OpenLineage distinguishes jobs, runs, and datasets, permitting execution
evidence to connect to declared data relationships [73]. W3C PROV supplies a vocabulary for entities,
activities, agents, and derivation [74].
These precedents support the federated system model: facts retain their sources and relationships
rather than being flattened into a universal object table. Reaktor adds executable boundaries, deployment
refinement, and change proposals, but must not claim that an imported catalog already proves complete
call structure. In particular, a missing relation in an incomplete scan cannot support a universal no-path
claim. The practical benefit depends on sustained source integration and freshness, not initial diagram
quality.
34.9 Testing, proof, and trusted computing bases
FoundationDB combines a deliberately constrained transactional substrate with layered functionality and
deterministic fault simulation [151]. Reaktor should borrow the discipline of making scheduling, time,
and failures controllable in test environments. Reproducible execution enables a failing interleaving to
become a regression test; it does not exhaust all possible histories in an unbounded production system.
AWS’s use of formal methods, IronFleet’s implementation-oriented distributed proofs, Anvil’s controller
verification, and seL4’s kernel verification demonstrate different assurance boundaries [131, 129, 125, 130].
They support a layered strategy rather than a single universal verifier. Reaktor can prove a finite structural
property, model-check an update protocol, and test a concrete adapter while recording that these results
establish different claims. The trusted computing base includes model extraction and enforcement paths
as well as the theorem checker. Omitted device assumptions or an unverified bridge remain relevant even
when a lower layer is proved.
Ginseng and Kitsune demonstrate that dynamic software updating is a longstanding systems problem
involving safe points and state transformation [152, 153]. Their relevance is methodological: replacement
must be part of the runtime semantics. Their guarantees do not transfer automatically to Hermes, shared
JavaScript module caches, or native UI objects. Reaktor’s update eligibility must be established for its
own loader, state model, and generation-retirement implementation.
34.10 What remains unvalidated
The precedents collectively support typed boundaries, shared descriptions, compilation, declarative
resource use, provenance, controlled updates, and scoped assurance. They do not establish that one product
should adopt all these mechanisms, that a broad integration is inexpensive, or that the workbench will be
easier to use than existing tools. Those are evaluation questions. The strongest defensible thesis is that
preserving relationships between the mechanisms creates opportunities for analysis and reuse that isolated
tools cannot provide as directly; the magnitude of the benefit is workload- and organization-dependent.
94
Page 95
Extracted text for page 95
Reaktor: An Extensible Software Engine Technical preprint
35 Evaluation agenda and limitations
35.1 Matched engineering conditions
The evaluation must test the engine claim, not only graph storage. Compare the same product change
in a competent conventional stack, Reaktor without agents, and matched agent-assisted conditions with
and without Reaktor’s semantic context. Hold acceptance requirements, source access, external tools,
model, and resource budgets comparable. Record separately the contribution of reusable modules, visual
authoring, graph context, and additional tool access.
The first task follows Section 3: implement a feature, run an isolated profile, deploy its compatible
components, investigate a deliberately injected cross-boundary failure, and perform one accepted and
one rejected update. Count independently maintained declarations, incompatible changes detected
before execution, investigation steps, review effort, accepted behavior, recovery quality, and framework
maintenance. Do not treat fewer lines of code as proof of reduced engineering work.
35.2 Limits of the model
General program behavior cannot be inferred completely from arbitrary source or sampled observations.
Sound analysis may overapproximate and reject some valid configurations. Stateful update closure may
be too large for independent replacement. Long-lived sessions can delay activation indefinitely under a
policy that forbids forced termination.
Native code, unsafe references, foreign runtimes, provider APIs, and external side effects remain
important trust boundaries. A shared process is not a hostile-code sandbox. A solver result is only as
sound as its encoding and assumptions. A cloud plan is not proof of live resource health. A bounded
check is not an unbounded theorem.
The architecture also carries engineering costs: contract maintenance, source mapping, adapter
conformance, storage complexity, and state-migration discipline. Its value depends on reducing errors and
duplicated reasoning enough to justify those costs. No new performance measurements, maintainer study,
or end-to-end implementation proof are reported. The finite reference model has the narrower reproduced
results stated below.
35.3 Falsifiable questions and comparison design
An evaluation should distinguish the cost of representing a system from the benefit of using the resulting
representation. Four questions are independently testable. Does typed elaboration prevent boundary
errors beyond a shared interface alone? Do indexed graph projections reduce investigation work relative
to source search and existing observability tools? Does the compiled execution path retain acceptable
overhead? Do update profiles reject unsafe changes and recover from the interruptions they claim to
tolerate?
The baselines should be serious alternatives: ordinary shared-interface code with generated clients;
existing framework dependency wiring; catalog plus source search; current deployment and telemetry
tooling; and a direct implementation of the same workload without Reaktor. Comparing against
an intentionally untyped, undocumented application would confound architectural value with basic
engineering hygiene.
Use a workload family rather than a single demonstration. Include a small offline app, a request/reply
service, a high-degree publication, a graph with many sparse facets, a frequently edited workbench
graph, a mixed-language imported system, and a stateful update region. Report the graph sizes, degree
distributions, attribute sizes, retained revisions, and query selectivity. A million isolated nodes is not a
substitute for a realistic dependency graph. Measure both binary-dominated and n-ary workloads without
clique expansion.
95
Page 96
Extracted text for page 96
Reaktor: An Extensible Software Engine Technical preprint
For runtime costs, report allocations, peak and steady-state memory, throughput, latency distributions,
and recovery time. Warm-up, compilation, garbage collection, and serialization must be separated where
meaningful. A fast median does not establish a deadline; a failure-free throughput test does not establish
recovery behavior. Publish target hardware, runtime versions, affinity and load conditions. Hardware
models in Section 25 are explanatory bounds, not measurements of these implementations.
35.4 Correctness, coverage, and failure campaigns
Seed known structural and semantic faults: incompatible schemas, duplicate owners, partial batch wiring,
stale query watermarks, omitted entry points, unsupported capabilities, duplicated effects, and callbacks
into retired generations. Check both detection and useful explanations. An analysis that rejects every
update is safe in a trivial sense but useless; report false rejection as well as missed violations against the
chosen reference model.
Update campaigns should interrupt artifact verification, preparation, state transfer, publication, retire-
ment, and recovery. Test memory pressure while two generations coexist, a permanently active session,
rollback after a new state write, and a missing native capability. Database and provider tests should
include failed observation distinct from confirmed absence. The expected outcomes must be declared
before running the campaign.
The finite explorer in Section 31 is a reproducible reference result within its explicitly enumerated state
space. It does not replace these implementation campaigns. A useful next step is to translate a discovered
abstract history into a deterministic runtime test and verify that the implementation either excludes or
safely handles that history.
35.5 Human and agent outcomes
For development tasks, measure accepted functionality, defects, review effort, diagnosis accuracy, and
maintenance cost rather than code volume. Use matched tasks and counterbalanced order where possible.
Keep model, token budget, source access, execution tools, and test access comparable when testing the
additional value of graph context. Otherwise an advantage may come from richer tool access rather than
from graph structure.
Reviewers should not be told which condition produced a patch when blinding is feasible. Protect
acceptance tests and verifier definitions from the proposer. Record rejected patches and abandoned
attempts, not only successful demonstrations. Current benchmark evidence already shows why test
passage and maintainer acceptance are distinct endpoints [121]. Industrial adoption studies also need
the cost of onboarding, provider maintenance, and migration; savings on one task can coexist with a net
increase in organizational cost.
35.6 Work experience as evidence
The motivating source snapshots and design memoranda are engineering observations, not controlled user
studies. They justify requirements such as shared service navigation and explicit runtime boundaries.
They do not establish general productivity multipliers. A claim based on practitioner experience should
identify the observed system, failure pattern, and scope, and should remain separate from a theorem,
published experiment, or independently reproduced measurement. No fictional deployment or customer
outcome is used as evidence in the constructed scenarios.
36 Implementation sequence and acceptance milestones
The first milestone is a complete, narrow authoring loop, not a complete workbench menu. A new project
composes one feature, runs it with explicit local bindings, exposes the same operation through a real
96
Page 97
Extracted text for page 97
Reaktor: An Extensible Software Engine Technical preprint
service adapter, and links a failure to its source and test. The photograph-message example is a suitable
reference specification; a smaller already-working messaging slice can be used for the first implementation.
Every integration in the demonstrated path must have a declared evidence status.
Kernel changes begin with stable identity, preserved node ownership, transactional connection
batches, actual-partner checks during disconnection, and rejection of ambiguous binding. The current
consumes/provides profile remains usable. The semantic snapshot and shared-service elaboration then
separate operation identity from HTTP exposure, with conformance tests for local and remote realizations.
Native n-ary edges add subscription identity without requiring clique expansion. Representation round
trips, boundary rules, and small Alloy/TLA+ models develop alongside the corresponding implementation.
The next authoring milestone is a supported Blueprint fragment with a text/graph round trip, typed
holes, source-linked findings, and one execution backend. A visual connection must create an ordinary
reviewable source/semantic change. General arbitrary-source round-tripping is not part of the milestone.
Reusable package metadata supplies the palette and parameter editor; handwritten business code remains
available through explicit interfaces.
The build/operations milestone connects authoritative target facts to the existing CLI, Desktop, and tool
runners. One feature’s artifact, deployment binding, cloud observation, and telemetry identity must be
navigable without a parallel fixture catalog. External resources are not labelled observed merely because
configuration names them. An isolated development profile precedes production replay. A bounded agent
can then use the same operations and return independently inspectable receipts.
LiveUpdate starts with one signed artifact per supported boundary, unchanged host-owned state,
next-entry or boundary-restart activation, and a tested recovery entrypoint. Drain-and-swap, schema
migration, and versioned coexistence are separate milestones. Runtime pooling, optimal packaging,
automatic placement of arbitrary source, and fleet-wide coordination are not prerequisites for the first
useful update.
Data-oriented storage replaces object structures where measured workloads justify it. Direct-call,
traversal, mutation, and retained-generation benchmarks guard against paying a global architectural tax
on a local interaction. Formal verification grows around stable interfaces: patch publication, update
ownership, and selected realization protocols are better early targets than an enormous unqualified model
of the whole product.
A milestone is complete when a new contributor can repeat its workflow from the source package,
distinguish every proposed step from implemented behavior, inspect its evidence, and recover from the
failures it claims to handle. The platform should earn broader scope by making those loops reusable.
37 Conclusion
Reaktor is an application-and-distributed-systems engine whose common representation is a typed,
attributed, hierarchical port hypergraph. Nodes own ports; binary edges and hyperedges express
connectivity; protocol profiles supply behavior. Open boundaries support composition, while deployment
refinement connects logical components to actual artifacts, processes, devices, transports, and resources.
The engine model changes the authoring relationship. Engineers implement difficult mechanisms and
expose their interfaces, lifecycle, tools, tests, and conditions of use. Product developers compose those
mechanisms in readable source or a Blueprint-style editor. Agents participate through the same contextual
queries and guarded operations. New mechanisms can expand the class of feasible applications, but only
under explicit host, resource, policy, and semantic constraints.
Concrete integrations are essential to this claim. Mobile adapters, web renderers, typed services, stores,
queues, native bridges, build tools, and cloud operations remain useful systems in their own right. The
graph connects their contracts and evidence; it does not replace them with one universal interpreter.
Data-oriented snapshots and compiled execution preserve a separation between architectural analysis and
routine invocation.
97
Page 98
Extracted text for page 98
Reaktor: An Extensible Software Engine Technical preprint
Formal methods make selected conditions precise and reusable. Structural validation, relational
analysis, model checking, simulation, refinement, and implementation proofs answer different questions.
LiveUpdate illustrates their joint role: replaceable code requires compatible boundaries, correct lifetimes,
state ownership, and recoverable activation, not merely successful delivery of a bundle.
The decisive evaluation is whether this integrated model lets people build, understand, operate, and
change real products with less duplicated reasoning and fewer boundary failures than competent existing
practice. The architecture establishes the interfaces and proof obligations for that evaluation; its broader
productivity and reliability gains remain empirical questions.
References
[1] Epic Games. Introduction to Blueprints. Official documentation. Documentation. Accessed September 2026.
[2] Epic Games. Coding in Unreal Engine: Blueprint vs. C++. Official documentation. Documentation. Accessed
September 2026.
[3] Reaktor Project. Framework Overview. Project documentation source, 2026. Pinned source; public route.
[4] Reaktor Project. Visual Language — Blueprints. Project documentation source, 2026. Pinned source; public
route.
[5] Reaktor Project. Reaktor Build Tools. Project documentation source, 2026. Pinned source; public route.
[6] Reaktor Project. Reaktor DevOps. Project documentation source, 2026. Pinned source; public route.
[7] Reaktor Project. Graph Kernel Analysis. Project documentation source, 2026. Pinned source; public route.
[8] Reaktor Project. Unified System Graph. Project documentation source, 2026. Pinned source; public route.
[9] Reaktor contributors. Reaktor source code. Graph kernel, graph runtime, and service modules. Source
baseline 42ccdc96e772a10ce9a6580274f73f3fa02e0acc, 2026. Repository snapshot.
[10] BestBuds Ventures. BestBuds application source: shared messaging API, service clients, test implementations,
and application graph. Source baseline dcc5df82e7cd6e8e6b7cd6ebd7f2bc37ef9ea43d, 2026. Private
project source. Repository snapshot.
[11] Epic Games. Technical Guide for Blueprints Visual Scripting. Official documentation. Documentation.
Accessed September 2026.
[12] Epic Games. Blueprint Debugger. Official documentation. Documentation. Accessed September 2026.
[13] Epic Games. Asset management in Unreal Engine. Primary assets, dependency tracking, loading, and
packaging. Official documentation. Accessed September 2026.
[14] Epic Games. Game Features and Modular Gameplay. Official documentation. Documentation. Accessed
September 2026.
[15] Epic Games. Gameplay Ability System. Abilities, effects, attributes and lifecycle. Official documentation.
Accessed September 2026.
[16] Reaktor Project. Auth Architecture and Redesign. Project documentation source, 2026. Pinned source; public
route.
[17] Reaktor Project. Reaktor Notifications. Project documentation source, 2026. Pinned source; public route.
[18] Reaktor Project. Shadow Dev Environment. Project documentation source, 2026. Pinned source; public route.
[19] Reaktor Project. Dependeasy. Project documentation source, 2026. Pinned source; public route.
[20] Reaktor Project. Reaktor CLI. Project documentation source, 2026. Pinned source; public route.
[21] Reaktor Project. Reaktor Core. Project documentation source, 2026. Pinned source; public route.
[22] Reaktor Project. Reaktor Service. Project documentation source, 2026. Pinned source; public route.
[23] Cloudflare. Service bindings. Official documentation. Documentation. Accessed September 2026.
[24] Cloudflare. Service bindings: Remote-procedure calls. Official documentation. Documentation. Accessed
September 2026.
98
Page 99
Extracted text for page 99
Reaktor: An Extensible Software Engine Technical preprint
[25] Reaktor Project. Actor Model. Project documentation source, 2026. Pinned source; public route.
[26] Reaktor Project. Reaktor FFI — Switchboard. Project documentation source, 2026. Pinned source; public
route.
[27] Reaktor Project. Engine and Website Implementation Report. Project documentation source, 2026. Pinned
source; public route.
[28] Reaktor Project. Graph Visitors. Project documentation source, 2026. Pinned source; public route.
[29] Gilles Kahn. The semantics of a simple language for parallel programming. In Information Processing
74: Proceedings of the IFIP Congress, pp. 471–475, North-Holland, 1974. The constructive treatment in
Reference [30] provides a machine-oriented account of the denotational model.
[30] Christine Paulin-Mohring. A constructive denotational semantics for Kahn networks in Coq. Chapter 17 in
From Semantics to Computer Science: Essays in Honour of Gilles Kahn. Cambridge University Press, 2010.
Publisher chapter.
[31] Reaktor Project. Hierarchical Graph UI. Project documentation source, 2026. Pinned source; public route.
[32] Simon Brown. The C4 model for visualising software architecture. Official documentation. Documentation.
Accessed September 2026.
[33] Reaktor Project. Flow Analysis. Project documentation source, 2026. Pinned source; public route.
[34] Mikko Kivelä, Alexandre Arenas, Marc Barthelemy, James P. Gleeson, Yamir Moreno, and Mason A. Porter.
Multilayer networks. Journal of Complex Networks, 2(3):203–271, 2014. arXiv:1309.7233.
[35] Reaktor Project. Reaktor architecture documents: Graph Kernel Analysis; Unified System Graph; Graph
Sources; Data Layer; Service Layer; Control Plane; Graph Visitors. Project design corpus, 2026. Documenta-
tion collection.
[36] Eric Lehman, F. Thomson Leighton, and Albert R. Meyer. Mathematics for Computer Science. MIT course
text, 2015. Course text and readings.
[37] Kohei Honda, Vasco T. Vasconcelos, and Makoto Kubo. Language primitives and type discipline for
structured communication-based programming. In European Symposium on Programming, LNCS 1381, pp.
122–138, 1998. doi:10.1007/BFb0053567. Subsequent session-type developments refine the definitions and
proof conditions; no session-type theorem is assumed for arbitrary Reaktor protocols.
[38] Joseph M. Hellerstein and Peter Alvaro. Keeping CALM: When distributed consistency is easy. Preprint,
2019. arXiv:1901.01930.
[39] Peter Bailis, Alan Fekete, Michael J. Franklin, Ali Ghodsi, Joseph M. Hellerstein, and Ion Stoica. Coordination
avoidance in database systems. Extended version, 2014. arXiv:1402.2237.
[40] Nancy A. Lynch. Distributed Algorithms. Morgan Kaufmann, 1996. ISBN 9781558603486. Companion
MIT course readings.
[41] Christel Baier and Joost-Pieter Katoen. Principles of Model Checking. MIT Press, 2008. ISBN 9780262026499.
Publisher page.
[42] Brendan Fong and David I. Spivak. Seven Sketches in Compositionality: An Invitation to Applied Category
Theory. Open manuscript, 2018. arXiv:1803.05316. Published as An Invitation to Applied Category Theory,
Cambridge University Press, 2019.
[43] Lucas Dixon and Aleks Kissinger. Open graphs and monoidal theories. Technical report, 2010.
arXiv:1011.4114.
[44] Nneka Chinelo Ene, Maribel Fernández, and Bruno Pinaud. Attributed hierarchical port graphs and applica-
tions. Electronic Proceedings in Theoretical Computer Science, 265:2–19, 2018. doi:10.4204/EPTCS.265.2.
arXiv:1802.06492.
[45] Philip Chodrow and Andrew Mellor. Annotated hypergraphs: Models and applications. Preprint, 2019.
arXiv:1911.01331.
[46] Giorgio Gallo, Giustino Longo, Stefano Pallottino, and Sang Nguyen. Directed hypergraphs and applications.
Discrete Applied Mathematics, 42(2–3):177–201, 1993. doi:10.1016/0166-218X(93)90045-P.
[47] GraphBLAS Forum. GraphBLAS: graph algorithms in the language of linear algebra. Mathematical
foundations and sparse-algebra interfaces. Project documentation. Accessed September 2026.
99
Page 100
Extracted text for page 100
Reaktor: An Extensible Software Engine Technical preprint
[48] J. A. Bondy and U. S. R. Murty. Graph Theory. Graduate Texts in Mathematics 244, Springer, 2008.
doi:10.1007/978-1-84628-970-5.
[49] Fan R. K. Chung. Spectral Graph Theory. CBMS Regional Conference Series in Mathematics 92. American
Mathematical Society, 1997. Author’s supporting material.
[50] Hartmut Ehrig, Karsten Ehrig, Ulrike Prange, and Gabriele Taentzer. Fundamentals of Algebraic Graph
Transformation. Springer, 2006. doi:10.1007/3-540-31188-2.
[51] Chris Lattner, Mehdi Amini, Uday Bondhugula et al. MLIR: A compiler infrastructure for the end of Moore’s
law. Preprint, 2020. arXiv:2002.11054.
[52] Edward A. Lee and David G. Messerschmitt. Synchronous data flow. Proceedings of the IEEE, 75(9):1235–
1245, 1987. Author publication page. doi:10.1109/PROC.1987.13876.
[53] Edward A. Lee and David G. Messerschmitt. Static scheduling of synchronous data flow programs for digital
signal processing. IEEE Transactions on Computers, C-36(1):24–35, 1987. Author publication page.
[54] Tadao Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541–580,
1989. doi:10.1109/5.24143.
[55] Alan M. Turing. On computable numbers, with an application to the Entscheidungsproblem. Proceedings of
the London Mathematical Society, s2-42(1):230–265, 1937; received 1936. doi:10.1112/plms/s2-42.1.230.
[56] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the
ACM, 21(7):558–565, 1978. doi:10.1145/359545.359563.
[57] James C. Corbett et al. Spanner: Google’s globally-distributed database. In USENIX Symposium on Operating
Systems Design and Implementation, 2012. Author publication page.
[58] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with
one faulty process. Journal of the ACM, 32(2):374–382, 1985. doi:10.1145/3149.214121.
[59] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony.
Journal of the ACM, 35(2):288–323, 1988. doi:10.1145/42282.42283.
[60] Seth Gilbert and Nancy Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-
tolerant web services. ACM SIGACT News, 33(2):51–59, 2002. doi:10.1145/564585.564601.
[61] Maurice P. Herlihy and Jeannette M. Wing. Linearizability: A correctness condition for concurrent objects.
ACM Transactions on Programming Languages and Systems, 12(3):463–492, 1990. doi:10.1145/78969.78972.
[62] Jerome H. Saltzer, David P. Reed, and David D. Clark. End-to-end arguments in system design. ACM
Transactions on Computer Systems, 2(4):277–288, 1984. Author-hosted paper.
[63] Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual
Technical Conference, pp. 305–319, 2014. Conference paper.
[64] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. In
Stabilization, Safety, and Security of Distributed Systems, LNCS 6976, pp. 386–400, 2011. doi:10.1007/978-
3-642-24550-3_29.
[65] Reaktor Project. Reaktor Capability. Project documentation source, 2026. Pinned source; public route.
[66] Reaktor Project. Component Lifecycle. Project documentation source, 2026. Pinned source; public route.
[67] Reaktor Project. BestBuds Architecture Refactor. Project documentation source, 2026. Pinned source; public
route.
[68] Reaktor Project. Graph Refinement Plan. Project documentation source, 2026. Pinned source; public route.
[69] Service Weaver project. Service Weaver: component-based application development and deployment. Project
documentation. Accessed September 2026.
[70] Hydro project. Location-Oriented Programming and Locations and Networking. Programming-model
documentation; location reference. Accessed September 2026.
[71] Reaktor Project. Reaktor Data Layer. Project documentation source, 2026. Pinned source; public route.
[72] Reaktor Project. BestBuds Schema Hardening. Project documentation source, 2026. Pinned source; public
route.
100
Page 101
Extracted text for page 101
Reaktor: An Extensible Software Engine Technical preprint
[73] OpenLineage project. Object Model. OpenLineage specification. Official specification. Accessed September
2026.
[74] Paul Groth and Luc Moreau, editors. PROV-Overview: An Overview of the PROV Family of Documents.
W3C Working Group Note, 30 April 2013. W3C specification.
[75] Bazel contributors. Hermeticity. Build-system documentation. Official documentation. Accessed September
2026.
[76] Eelco Dolstra. The Purely Functional Software Deployment Model. Ph.D. thesis, Utrecht University, 2006.
Project publication announcement.
[77] Reaktor Project. Multitenancy. Project documentation source, 2026. Pinned source; public route.
[78] Reaktor Project. Reaktor Secrets. Project documentation source, 2026. Pinned source; public route.
[79] Reaktor Project. Security Plan — MLS end-to-end encryption. Project documentation source, 2026. Pinned
source; public route.
[80] Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, and Katriel Cohn-
Gordon. The Messaging Layer Security (MLS) Protocol. RFC 9420, IETF, July 2023. Official specification.
doi:10.17487/RFC9420.
[81] Reaktor Project. Reaktor Work. Project documentation source, 2026. Pinned source; public route.
[82] Android Developers. Persistent background work. Official documentation. Documentation. Accessed Septem-
ber 2026.
[83] Apple. Choosing background strategies for your app. Official documentation. Documentation. Accessed
September 2026.
[84] Reaktor Project. Reaktor Bus. Project documentation source, 2026. Pinned source; public route.
[85] Reaktor Project. Reaktor Mesh. Project documentation source, 2026. Pinned source; public route.
[86] Firebase. Setting the lifespan of a message. Official documentation. Documentation. Accessed September
2026.
[87] Reaktor Project. Deep Link Integration. Project documentation source, 2026. Pinned source; public route.
[88] Reaktor design materials. LiveUpdate and cross-runtime execution. Unpublished architecture memorandum,
2026. Execution domains, artifact requirements, Hermes regions, FFI dispatch, state policy, and update
generations.
[89] Reaktor Project. Reaktor FlexBuffer Performance Guide. Project documentation source, 2026. Pinned source;
public route.
[90] Reaktor Project. Reaktor UI and Tactile. Project documentation source, 2026. Pinned source; public route.
[91] Reaktor Project. React × Compose Blueprint. Project documentation source, 2026. Pinned source; public
route.
[92] Reaktor Project. React × Compose Interop Roadmap. Project documentation source, 2026. Pinned source;
public route.
[93] React Native contributors. Bundled Hermes. React Native architecture documentation. Official documentation.
Accessed September 2026.
[94] Dagger Project. CI integrations: Jenkins. Official documentation. Documentation. Accessed September
2026.
[95] Pulumi. Automation API. Official documentation. Documentation. Accessed September 2026.
[96] Reaktor Project. Reaktor Cloud Control Plane. Project documentation source, 2026. Pinned source; public
route.
[97] Reaktor Project. Analytics and Telemetry. Project documentation source, 2026. Pinned source; public route.
[98] Reaktor Project. Performance and Observability. Project documentation source, 2026. Pinned source; public
route.
[99] Reaktor Project. Graph Sources. Project documentation source, 2026. Pinned source; public route.
101
Page 102
Extracted text for page 102
Reaktor: An Extensible Software Engine Technical preprint
[100] Epic Games. Overview of Mass Entity. Unreal Engine documentation. Official documentation. Accessed
September 2026.
[101] Epic Games. Render Dependency Graph. Unreal Engine documentation. Official documentation. Accessed
September 2026.
[102] Richard Fabian. Data-Oriented Design: Software Engineering for Limited Resources and Short Schedules.
2018. Author’s site and online text.
[103] Samuel Williams, Andrew Waterman, and David Patterson. Roofline: An insightful visual performance model
for multicore architectures. Communications of the ACM, 52(4):65–76, 2009. doi:10.1145/1498765.1498785.
Earlier author technical report.
[104] Gene M. Amdahl. Validity of the single processor approach to achieving large scale computing capabilities.
In AFIPS Spring Joint Computer Conference, pp. 483–485, 1967. doi:10.1145/1465482.1465560.
[105] John D. C. Little. A proof for the queuing formula: 𝐿 = 𝜆𝑊. Operations Research, 9(3):383–387, 1961.
doi:10.1287/opre.9.3.383.
[106] Linux kernel contributors. What is RCU?—Read, Copy, Update. Kernel documentation. Official documenta-
tion. Accessed September 2026.
[107] Bureau International des Poids et Mesures. The International System of Units (SI). Ninth edition, 2019, with
online supporting material. Definitions and measurement units.
[108] Expo. Runtime versions and updates. EAS Update documentation. Official documentation. Accessed
September 2026.
[109] Expo. Error recovery. EAS Update documentation. Official documentation. Accessed September 2026.
[110] The Update Framework. Roles and metadata. Official documentation. Accessed September 2026.
[111] Apple. App Review Guidelines, including Section 2.5.2. Official policy. Accessed September 2026. Distribu-
tion rules require review for the applicable release channel.
[112] Google. Device and network abuse. Google Play Developer Program Policy. Official policy. Accessed
September 2026.
[113] Reaktor Project. Agentic Tooling / Control Plane. Project documentation source, 2026. Pinned source; public
route.
[114] Reaktor Project. Koog Workbench. Project documentation source, 2026. Pinned source; public route.
[115] Reaktor Project. Gemini DevOps Agent. Project documentation source, 2026. Pinned source; public route.
[116] Reaktor Project. Koog for the BestBuds Bot. Project documentation source, 2026. Pinned source; public
route.
[117] Reaktor Project. Browser-Local AI. Project documentation source, 2026. Pinned source; public route.
[118] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and
Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. Preprint, 2024.
arXiv:2405.15793.
[119] Anthropic. Effective harnesses for long-running agents. Engineering report, 2025. Report.
[120] OpenAI. Harness engineering: leveraging Codex in an agent-first world. Engineering report, 2026. Report.
[121] Parker Whitfill, Cheryl Wu, Joel Becker, and Nate Rush. Many SWE-bench passing PRs would not be merged
into main. METR research note, 10 March 2026. Study report. The experiment concerns its specified agents,
repositories, and review procedure, not a general bound on future systems.
[122] Daniel Jackson. Software Abstractions: Logic, Language, and Analysis. Revised edition, MIT Press;
paperback edition, 2016. ISBN 9780262528900. Publisher page.
[123] Nikolaj Bjørner, Leonardo de Moura, Lev Nachmanson, and Christoph Wintersteiger. Programming Z3.
Online technical tutorial. Author-maintained text. Accessed September 2026.
[124] Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers.
Addison-Wesley, 2002. Author’s book and supporting material.
102
Page 103
Extracted text for page 103
Reaktor: An Extensible Software Engine Technical preprint
[125] Xudong Sun, Wenjie Ma, Jiawei Tyler Gu, Zicheng Ma, Tej Chajed, Jon Howell, Andrea Lattuada, Oded
Padon, Lalith Suresh, Adriana Szekeres, and Tianyin Xu. Anvil: Verifying liveness of cluster management
controllers. In 18th USENIX Symposium on Operating Systems Design and Implementation, pp. 649–666,
2024. Conference publication.
[126] Jeremy Avigad, Leonardo de Moura, Soonho Kong, and Sebastian Ullrich. Theorem Proving in Lean 4.
Online textbook. Official text. Accessed September 2026.
[127] NASA. Systems Engineering Handbook, Section 2: Fundamentals of systems engineering. NASA/SP-2016-
6105 Rev. 2, online edition. Handbook section. Accessed September 2026.
[128] NASA. Systems Engineering Handbook, Section 5: Product realization. NASA/SP-2016-6105 Rev. 2, online
edition. Handbook section. Accessed September 2026.
[129] Chris Hawblitzel, Jon Howell, Manos Kapritsos, Jay R. Lorch, Bryan Parno, Justine Stephenson, Srinath
Setty, and Brian Zill. IronFleet: Proving practical distributed systems correct. In ACM Symposium on
Operating Systems Principles, 2015. Author publication page.
[130] Gerwin Klein et al. seL4: Formal verification of an OS kernel. In ACM Symposium on Operating Systems
Principles, 2009. doi:10.1145/1629575.1629596. Project explanation of proof scope and assumptions.
[131] Chris Newcombe, Tim Rath, Fan Zhang, Bogdan Munteanu, Marc Brooker, and Michael Deardeuff. How
Amazon Web Services uses formal methods. Communications of the ACM, 58(4):66–73, 2015. Author
publication page. doi:10.1145/2699417.
[132] Open Robotics and ROS 2 contributors. About quality of service settings. ROS 2 Humble documentation.
QoS concepts and compatibility. Accessed September 2026.
[133] Geoffrey Biggs and Tully Foote. Managed nodes. ROS 2 design document, 2015, revised 2021. Design
specification.
[134] Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. HyTech: A model checker for hybrid systems.
International Journal on Software Tools for Technology Transfer, 1:110–122, 1997. Project and publications.
[135] Thomas A. Henzinger, Peter W. Kopke, Anuj Puri, and Pravin Varaiya. What’s decidable about hybrid
automata? Technical Report UCB/ERL M98/22, University of California, Berkeley, 1998. Technical report.
[136] Aaron D. Ames, Samuel Coogan, Magnus Egerstedt, Gennaro Notomista, Koushil Sreenath, and Paulo
Tabuada. Control barrier functions: Theory and applications. In European Control Conference, pp. 3420–3431,
2019. arXiv:1903.11199. doi:10.23919/ECC.2019.8796030.
[137] Karl J. Åström and Richard M. Murray. Feedback Systems: An Introduction for Scientists and Engineers.
Princeton University Press, 2008. Author-hosted first edition.
[138] Reaktor Project. Reaktor Arena. Project documentation source, 2026. Pinned source; public route.
[139] Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software:
You own your data, in spite of the cloud. In ACM SIGPLAN International Symposium on New Ideas, New
Paradigms, and Reflections on Programming and Software, pp. 154–178, 2019. Author-hosted essay and
paper. doi:10.1145/3359591.3359737.
[140] Don Batory. Feature models, grammars, and propositional formulas. In Software Product Lines, LNCS 3714,
pp. 7–20, Springer, 2005. doi:10.1007/11554844_3.
[141] Reaktor Project. Nexergy Energy on Reaktor — Codex. Project documentation source, 2026. Pinned source;
public route.
[142] Reaktor Project. Nexergy Commerce Substrate — Claude. Project documentation source, 2026. Pinned
source; public route.
[143] Martín Abadi et al. TensorFlow: A system for large-scale machine learning. In USENIX Symposium on
Operating Systems Design and Implementation, pp. 265–283, 2016. Conference paper.
[144] Reaktor Project. CompanyOS Migration. Project documentation source, 2026. Pinned source; public route.
[145] Epic Games. Replication Graph. Official documentation. Accessed September 2026.
[146] Xavier Leroy and CompCert contributors. The CompCert C compiler: a trustworthy compiler. Manual,
overview and semantic-preservation guarantees. Official manual. Accessed September 2026.
103
Page 104
Extracted text for page 104
Reaktor: An Extensible Software Engine Technical preprint
[147] Harshit Saokar et al. ServiceRouter: Hyperscale and minimal cost service mesh at Meta. In USENIX
Symposium on Operating Systems Design and Implementation, pp. 969–985, 2023. Conference paper.
[148] Ruoming Pang et al. Zanzibar: Google’s consistent, global authorization system. In USENIX Annual Technical
Conference, 2019. Author publication page.
[149] Dapr Project. Building blocks. Official documentation. Documentation. Accessed September 2026.
[150] Backstage contributors. Software catalog and Well-known relations between catalog entities. Catalog
documentation; Relation semantics. Accessed September 2026.
[151] Jingyu Zhou et al. FoundationDB: A distributed unbundled transactional key value store. In ACM SIGMOD
International Conference on Management of Data, pp. 2653–2666, 2021. doi:10.1145/3448016.3457559.
Project publication summary.
[152] Iulian Neamtiu, Michael Hicks, Gareth Stoyle, and Manuel Oriol. Practical dynamic software updating for C.
In ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 72–83, 2006.
Author publication page.
[153] Christopher M. Hayden, Edward K. Smith, Michail Denchev, Michael Hicks, and Jeffrey S. Foster. Kitsune:
Efficient, general-purpose dynamic software updating for C. In ACM International Conference on Object Ori-
ented Programming Systems Languages and Applications, pp. 249–264, 2012. doi:10.1145/2384616.2384635.
[154] Robert Nystrom. Crafting Interpreters. Genever Benning, 2021. Author’s online edition.
[155] Keith D. Cooper and Linda Torczon. Engineering a Compiler. Second edition, Morgan Kaufmann, 2011.
Publisher page.
[156] Jason Gregory. Game Engine Architecture. Third edition, CRC Press, 2018. Author’s companion site.
[157] Victor Dibia. Designing Multi-Agent Systems: Principles, Patterns, and Implementation. Online book.
Author’s site. Accessed September 2026.
104
Page 105
Extracted text for page 105
Reaktor: An Extensible Software Engine Technical preprint
A Notation and representation interfaces
Table 13 summarizes the principal objects. The notation separates identities, semantic descriptions, and
implementation handles throughout the architecture.
Symbol or object Meaning
𝑁, 𝑃, 𝐸, 𝐽 Nodes, owned ports, edges, and incidence occurrences.
𝑜, 𝑎, 𝑏, 𝑟 Ownership, incidence-to-edge, incidence-to-port, and role maps.
𝜏, 𝐹 Type assignments and schema-checked attributes.
𝑀 = (𝐻, 𝐵, 𝛽) An open module and its exposed owned endpoints.
𝜂(𝑥) The interaction semantics of edge 𝑥.
⟦𝐻⟧ A behavioral transition-system interpretation.
𝜌 Logical-to-physical realization mapping.
𝑅 A release mapping compatible graph, artifact, and boundary revisions.
𝑈, 𝑈 ′ Old and replacement update regions.
Δ A revision-relative graph patch.
𝛼 The abstraction from physical storage to the semantic graph.
𝜑, 𝐴 A property and its assumptions.
Table 13: Core notation. Observation times and runtime generations are not interchangeable with semantic revision
identifiers.
The following record sketch illustrates a compact semantic API. Each identifier is an opaque, scoped
identity; implementations can intern it to a dense index. Referenced descriptor types are versioned records
defined by the corresponding subsystem.
105
Page 106
Extracted text for page 106
Reaktor: An Extensible Software Engine Technical preprint
data class NodeSpec(
val id: NodeId, val kind: NodeKindId,
val scope: ScopeId, val implementation: ImplementationRef?,
)
data class PortSpec(
val id: PortId, val owner: NodeId,
val name: SymbolId, val endpointType: EndpointTypeId,
val bindingCardinality: Cardinality,
)
data class EdgeSpec(
val id: EdgeId, val edgeType: EdgeTypeId,
val semantics: InteractionProfileId,
)
data class IncidenceSpec(
val id: IncidenceId, val edge: EdgeId, val port: PortId,
val role: RoleId, val membership: MembershipPolicyId?,
)
data class UpdateManifest(
val release: ReleaseId, val expectedBase: ReleaseId,
val region: UpdateRegionId, val patch: GraphPatch,
val artifacts: List<ArtifactRef>,
val hostRequirements: HostRequirements,
val activation: ActivationPlan,
val stateTransition: StateTransitionPlan,
val recovery: RecoveryPlan,
)
B Update failure obligations
A recovery test suite should cover each transition that can leave durable state different from the currently
published execution view. Table 14 gives the minimum categories; individual adapters can require
additional cuts.
Table 14: Failure cases and required outcomes for a supported update profile.
Failure point Risk Required behavior
Interrupted download Partial or inconsistent artifacts Do not load until authenticated content and
dependency checks succeed.
Candidate initialization Unintended production effects Deny unapproved effects; discard isolated
staged resources on failure.
Safe point unavailable Forced interruption of a Defer, use an explicitly approved
session or writer termination policy, or reject activation.
Migration interrupted Partially converted durable Resume or recover from a recorded
state migration phase; never infer schema from
artifact selection alone.
Ownership transferred Old execution view with a Enforced fencing rejects old writes;
before publication stale writer recovery selects a compatible generation or
a restricted state.
106
Page 107
Extracted text for page 107
Reaktor: An Extensible Software Engine Technical preprint
Failure point Risk Required behavior
Publication completed Uncertain updater outcome Read the durable release/journal state and
before resolve idempotently.
acknowledgement
Delayed callback after Dispatch into a reused slot Validate registry and generation; reject or
swap deliver to a still-protected old generation.
Candidate fails after Unsafe code rollback Use only a state-compatible recovery
writes artifact or an authorized forward repair.
Old generation never Unbounded retained memory Apply a declared lifetime/termination
drains policy; retain safety even if retirement is
delayed.
Stale signed metadata Unauthorized downgrade or Enforce freshness, version, trust-root, and
mixed release coherent snapshot rules.
C Terminology and reading conventions
The terms below distinguish concepts that are often conflated in architecture diagrams. They are definitions
used by this specification, not claims that every community uses the same vocabulary.
Term Meaning in this specification
Engine Reusable implementation mechanisms and their authoring, execution, lifecycle,
and tooling contracts; not one mandatory global runtime.
Blueprint A supported visual/textual behavior language over a reified graph, distinct from
a dependency diagram or UI render tree.
Feature package A versioned open module with the implementations and companions needed for
its declared support profile.
Node A semantic component or entity with an identity. A node need not be a heap
object, process, or independently deployed service.
Port An interface endpoint owned by exactly one node. Its type includes a signature,
protocol shape, and endpoint role.
Edge / hyperedge A structural connection with two or multiple incidence occurrences,
respectively. Behavior is supplied by its protocol and coordination profile.
Incidence One attachment occurrence linking an edge, port, and role. Distinct incidences
preserve repeated roles and subscription identities.
Protocol A specification of permitted observable communication, including sequencing,
completion, cancellation, and applicable errors.
Realization An implementation of a logical component or connection using artifacts,
runtimes, resources, and adapters.
Reference Access to a local interface or capability. It is not automatically serializable or
remotely realizable.
Relation A typed semantic connection between entities, such as declaration, protection,
lineage, ownership, or observation.
Facet Typed local metadata attached to an entity; not a substitute for a topology with
independent relationships.
Aspect A related vocabulary and topology, such as authorization or data lineage,
anchored to system identities.
Projection A query-derived view with stated filtering and completeness. Different
projections can legitimately have different paths.
107
Page 108
Extracted text for page 108
Reaktor: An Extensible Software Engine Technical preprint
Term Meaning in this specification
Open module A subgraph with explicit exposed boundary endpoints and internal ownership.
Composition connects boundaries without giving a port two owners.
Authority The source or protocol permitted to establish a class of facts. It is not
synonymous with a physical server or organizational contact.
Desired state Declared configuration or intended deployment. It does not imply current
physical existence.
Observation Evidence obtained from an execution or provider, with provenance, time, and
coverage limits.
Runtime instance A particular executing realization of a logical component. Several instances can
realize one logical node.
Invocation / attempt An invocation is the logical unit of requested work; an attempt is one execution
or delivery effort associated with it.
Graph revision A coherent version of structural declarations and compatible references within
an authority boundary.
Execution view The compatible mapping of bindings and versions used by a unit of work. Its
lifetime may outlast the current graph revision.
Update region A supported open subgraph whose replacement is mediated through declared
interfaces and lifecycle rules.
Generation A runtime incarnation of a replaceable boundary. It is distinct from an artifact
hash, schema version, and UI sequence.
Safe point A condition at which a specified update transition is permitted. It may concern
calls, state, resources, or physical machinery.
Fencing epoch A value checked by the effect authority to reject obsolete owners. A lease or
local generation counter alone is not equivalent enforcement.
Recovery An authorized transition from a failure state to an acceptable state. It may
require forward repair rather than code rollback.
Invariant A predicate required to hold in every reachable state of the specified model.
Safety / liveness Safety excludes forbidden finite behavior; liveness requires eventual progress
under stated assumptions.
Refinement A relation establishing that a more concrete model satisfies the relevant abstract
behavior and obligations.
Assurance evidence A scoped result: proof, bounded check, test, observation, or assumption. These
categories are not interchangeable.
Feasible system space Systems realizable under selected mechanisms, policies, environments, and
budgets. It is not generally a vector space.
Escape hatch An explicitly identified path outside a supported analyzable dialect. It requires
conservative summaries or a reduced assurance claim.
D Reproducibility of the finite reference model
The accompanying source archive contains models/generation_model.py and models/results.j
son. The script uses the Python standard library and performs breadth-first exploration of a deliberately
finite generation-lifetime model. Running the following command from the archive root regenerates the
result file:
python3 models/generation_model.py --output models/results.json
The result records the configured reader and generation bounds, transition counts, safety outcomes, and
the unsafe protocol’s counterexample. The model represents acquisition, release, monotonic publication,
108
Page 109
Extracted text for page 109
Reaktor: An Extensible Software Engine Technical preprint
and reclamation. Generations are prepared initially; no implementation code is dynamically loaded by the
experiment.
The finite result is useful because a common implementation error has a short witness, and the safe
model’s reachable-state counts also admit the independent combinatorial cross-check in Section 31. The
artifact does not test Reaktor’s current Kotlin, C++, or Hermes implementation. It does not model memory
ordering, crashes, state migration, counter overflow, or arbitrary future generations. Extending those
assumptions changes the model and requires a new result.
The LaTeX source is self-contained and includes the bibliography and vector diagrams. Compilation
requires a conventional TeX distribution with the packages declared in the preamble. The source archive
records the commands used to generate the PDF and model output. Citation URLs identify literature and
source baselines; private project references are not required to understand or run the finite example.
E Study guide and implementation exercises
The curriculum follows the architecture’s dependencies rather than treating its bibliography as a reading
queue. Each stage should produce a small implementation, model, counterexample, or measurement.
The learning nodes and prerequisite relations can be entered into Manna, with artifact completion as
evidence of mastery. The sequence is suitable for a systems programmer developing mathematical fluency;
experienced readers can enter at the relevant branch.
E.1 Stage 1: relations, logic, and proof
Begin with the relations, induction, state-machine, and invariant material in Mathematics for Computer
Science [36]. Use Bondy and Murty [48] for directed graphs, connectivity, cuts, and related algorithms.
Read Jackson’s Software Abstractions [122] alongside these topics, so that a mathematical definition
immediately becomes a model that can produce counterexamples.
Artifact. Define nodes, owned ports, incidence occurrences, roles, and open boundaries in a small
relational model. Include parallel edges and two distinct incidences involving the same endpoint. Check
invalid ownership, missing references, and ambiguous bindings. Implement a graph-to-incidence encoding
and test round-trip identity preservation on generated examples.
Completion criterion. Explain the difference between assuming an invariant and checking that a
transition preserves it. Produce at least one counterexample and revise either the model or the intended
rule. A correct diagram without a defined transition is not completion.
E.2 Stage 2: network representations and linear algebra
Study incidence and adjacency matrices, sparse representations, connected components, and eigenvectors.
Fong and Spivak’s signal-flow material [42], Chung’s spectral treatment [49], and GraphBLAS’s sparse-
algebra vocabulary [47] connect algebra to graph operations. Read the multilayer-network and hypergraph
references selectively for representation choices [34, 45, 46].
Artifact. Encode a publication and an AND-join with the same endpoint sets. Compute their incidence-
derived structural adjacency, then demonstrate why identical reachability does not imply identical enabling
behavior. Partition a measured toy workload using a declared cost function and compare the result with
an exact enumeration of its small candidate space.
Completion criterion. Explain which information each projection loses. Use a vector for numerical
objectives without claiming that arbitrary application architectures form a vector space.
109
Page 110
Extracted text for page 110
Reaktor: An Extensible Software Engine Technical preprint
E.3 Stage 3: execution semantics and computability
Use Nystrom [154] for a concrete interpreter and Cooper and Torczon [155] for intermediate representations
and lowering. Read Kahn-network semantics and its constructive treatment [29, 30], synchronous
dataflow [52, 53], Petri nets [54], and Turing’s computability argument [55] as distinct models rather than
interchangeable graph formalisms.
Artifact. Build a small executable behavior dialect with conditions, iteration, state, and explicit effects.
Implement a statically rated streaming fragment, derive its balance equations, and show a bounded-buffer
deadlock that the unbounded idealization excludes. Sketch a Turing-machine simulation using the dialect’s
explicit storage assumptions.
Completion criterion. State where termination is decidable in the implemented subset, where it is
only checked within bounds, and why unrestricted completeness limits automatic verification.
E.4 Stage 4: distributed algorithms and consistency
Lynch’s Distributed Algorithms [40] supplies I/O automata, failure models, composition, and simulations.
Read Lamport’s clock paper [56], linearizability [61], FLP, partial synchrony, and CAP with their exact
hypotheses [58, 59, 60]. Study Raft [63] as a concrete protocol, not as a synonym for every replicated
system. Use invariant confluence and CRDTs [39, 64] to reason about which independent updates can
merge safely.
Artifact. Implement one shared service interface with local and remote realizations. Introduce a lost
response after a committed update. Specify scoped deduplication, a durable outbox, and a checkpoint-
based read-your-writes path. Build an actor ownership model in which a stale holder is rejected at the
protected resource.
Completion criterion. Distinguish request failure from unknown outcome, arrival order from causal
order, and a failure detector’s suspicion from proof that an old owner has stopped.
E.5 Stage 5: specification and model checking
Read Lamport’s Specifying Systems [124], then use Baier and Katoen [41] for transition systems, safety,
liveness, fairness, abstraction, and temporal logic. Jackson remains useful for the relational side. The Z3
tutorial [123] provides a separate path for configuration and placement constraints.
Artifact. Reproduce the supplied generation-lifetime model, then extend it with an interruption during
preparation or with a stateful handoff. Build small TLA+ models for patch publication and queue delivery.
Remove a fairness assumption and identify the resulting non-progress behavior. Encode a placement
problem with satisfiable and inconsistent configurations, preserving unknown results as unknown.
Completion criterion. Write the model scope and assumptions next to every result. Translate a
counterexample into a test that exercises an actual boundary implementation.
E.6 Stage 6: hardware and data-oriented execution
Fabian [102] supplies an access-pattern perspective; Gregory [156] connects memory, execution, tools,
and lifecycle in an engine. Use Roofline, Amdahl’s law, Little’s law, and RCU [103, 104, 105, 106]
to predict costs before measuring them. Unreal’s RDG and MassEntity show concrete separation of
declarations, processing, and storage [101, 100].
Artifact. Compare object-oriented, compact binary/n-ary, and incidence-based graph stores behind
the same semantic API. Measure traversal, patches, allocations, direct-call overhead, and peak memory
during coexistence. Add safe publication, reader pinning, and retirement. Check stable identity after
compaction.
110
Page 111
Extracted text for page 111
Reaktor: An Extensible Software Engine Technical preprint
Completion criterion. Explain at least one mismatch between a simple performance model and
observed behavior. Do not declare one layout universally superior; identify the workloads for which it
wins and loses.
E.7 Stage 7: composition, rewriting, and extensions
Study Fong and Spivak’s database, signal-flow, circuit, and behavioral examples [42], then hierarchical
port graphs and open graphs [44, 43]. Ehrig and colleagues [50] develop typed rewriting, preserved
interfaces, and application conditions. Batory’s feature-model connection to propositional logic [140] is
useful for product families and configuration constraints.
Artifact. Specify ownership-preserving module composition, implement a structural patch checker,
and document its deletion conditions. Package one new protocol or runtime realization with its typing
rules, lifecycle, effects, tests, inspection metadata, and assurance obligations. Demonstrate a previously
infeasible scenario under a fixed environment and identify the assumptions needed for conservative
extension.
Completion criterion. Explain which theorem applies to the chosen encoding and why a structural
composition law does not automatically prove behavioral compatibility.
E.8 Stage 8: dynamic updating and recovery
Ginseng and Kitsune [152, 153] expose safe points and state transformation. Hermes and Expo
documentation [93, 108, 109] connect update artifacts to installed runtimes. TUF [110] supplies the
update trust model.
Artifact. Implement one replaceable boundary with signed artifacts, explicit host requirements,
unchanged host-owned state, next-entry activation, and independent recovery. Interrupt every journal
transition. Only after that profile works, add draining and generation coexistence. Include a callback into
an obsolete generation, a missing native capability, and a migration for which code rollback is unsafe.
Completion criterion. Separate artifact identity, successful loading, safe activation, authorization, and
distribution-channel eligibility. Demonstrate both an accepted update and a correctly rejected one.
E.9 Stage 9: system engineering, data, and robotics
NASA’s systems-engineering material [127, 128] supplies requirements decomposition, traceability,
verification, and validation. PROV and OpenLineage [74, 73] support source and execution evidence. For
the cyber-physical branch, read Feedback Systems [137], ROS lifecycle and QoS design [133, 132], and
selected hybrid-system and barrier-function material [134, 136].
Artifact. Connect a dataset authority, local mirror, and analytical projection with explicit checkpoints
and provenance. Separately construct a simulated robot pipeline whose interfaces record units, frames,
clock uncertainty, and freshness. Link a transport-delay assumption to a stopping-envelope requirement.
Permit planning updates while preserving a separately controlled local safety mechanism.
Completion criterion. Explain why an annotation does not verify calibration, why telemetry is not
control-theoretic observability, and why a simulation result is not a safety certification.
E.10 Stage 10: implementation proofs and human–agent tools
Use Lean’s official text [126] to mechanize one small structural theorem. Study CompCert, IronFleet,
seL4, and Anvil [146, 129, 130, 125] for different implementation/refinement boundaries. Dibia [157],
SWE-agent, and the harness-engineering reports [118, 119, 120] cover orchestration and development
feedback.
111
Page 112
Extracted text for page 112
Reaktor: An Extensible Software Engine Technical preprint
Artifact. Link a representation theorem to the graph store or validate a lowering result with a small
checker. Build a bounded context query, a typed change proposal, isolated checks, and a review step.
Protect verifier and policy definitions from the proposer. Compare matched development tasks with and
without the additional graph context, including unsuccessful attempts.
Completion criterion. Name the remaining trusted code and assumptions. Judge agent assistance by
accepted behavior and review cost rather than output volume. Demonstrate that an instruction embedded
in source text cannot authorize a protected operation.
E.11 An authoring and integration practicum
Study Unreal’s Blueprint introduction, technical guide, and debugger [1, 11, 12] alongside the Reaktor
visual-language design [4]. Implement one reusable feature definition and two instances with different
configuration. Give it a textual form, a visual projection, and a source-linked validation error. Distinguish
generated implementation from the source that owns the declaration.
Then trace that feature through Dependeasy/CLI target facts, a local test binding, one real service
adapter, an artifact, and an observation [5, 20, 6]. The exercise is complete only when a contributor can
identify what the framework derives, what an external tool executes, and what remains an application
decision. A beautiful graph that cannot run or a successful build that cannot be connected to the selected
feature is incomplete.
E.12 Capstone and priorities
The first complete project should be a shared-interface messaging feature with node-owned ports, a
publication hyperedge, a scoped commit/deduplication protocol, a data projection, and a supported
update region. Provide a local realization, a distributed realization, a deterministic failure harness, and a
workbench view connected to the same source identities.
The initial study spine is relational modeling, executable semantics, distributed state machines, and
measurement. Category theory, advanced hybrid analysis, and proof assistants become most useful after a
concrete obligation exists. Completion is not the number of books read or the number of graph primitives
introduced. It is agreement between the specification, models, counterexamples, tests, measurements, and
the behavior of a running system.
F Source lineage, maturity, and explicit design decisions
F.1 Documentary baseline
The reference stack is grounded in the Reaktor and BestBuds source baselines cited in References [9, 10],
the public documentation sources under targets/reaktorWeb/docusaurus/docs, and the LiveUpdate
memorandum [88]. The documentation audit enumerated 70 public routes from the site’s configuration,
sidebar, manifest, and page sources. Private documentation was excluded. The deployed website and
sitemap were unavailable to the audit, so correspondence between those sources and the current deployed
website was not established. Public URLs in the references are discovery links; the pinned source
inventory is the evidence baseline.
The corpus is not one synchronized specification. It includes implemented-substrate reports, proposed
architectures, product designs that assume framework completeness, alternative decompositions, critiques,
and merged stubs. Claims of implementation are attributed to their source, not promoted to an independently
reproduced current deployment. This manuscript reports no new Reaktor application build, mobile run,
cloud deployment, or measured performance experiment. The finite generation explorer is the separately
reproducible artifact described in Appendix D.
112
Page 113
Extracted text for page 113
Reaktor: An Extensible Software Engine Technical preprint
The companion source package includes a 70-route coverage/disposition map linking the audit to
the sections of this manuscript. Index pages and merged stubs are not independent missing subsys-
tems. Historical roadmaps and implementation schedules are not carried forward as current delivery
commitments.
F.2 Maturity interpretation
Source category Interpretation in the manuscript
Source-reported An implementation or tested slice described by the cited code/report. It
implementation supports an engineering example, not a complete end-to-end assurance
claim.
Source proposal A design specified in a canonical module page. Interfaces and target
workflows are explanatory, not proof of availability.
Specification decision The architecture defined here, including stricter distinctions needed for the
port-hypergraph, assurance, and update model. Divergence from a source
proposal is explicit below.
Constructed study An application scenario designed to expose requirements, tradeoffs, and
potential benefits. No deployment or productivity outcome is implied.
Established result A result attributed to literature or an existing system, used only under its
stated assumptions.
Reproduced finite result Enumeration of the attached abstract generation model. Scope excludes
production memory models, migration, distributed rollout, and actual
runtime code.
The documented foundation includes useful graph composition, shared service interfaces, local actor
execution, platform/store adapters, native bridge experiments, build conventions, and shared web/desktop
workbench structure. The documentation separately marks important capability normalization, general
Blueprint execution, full graph mutation/federation, bus/mesh composition, generalized Switchboard, UI
host-tree interop, and LiveUpdate as proposed or incomplete [21, 22, 25, 26, 4, 27]. Fine-grained source
status belongs in implementation release records rather than being inferred from the architecture’s use of
a module name.
F.3 Decisions that must not be silently merged
Source tension Decision in this specification
Transport-bearing service Preserve shared service APIs, but separate operation/protocol identity from
types HTTP, Worker, FFI, and broker realizations (Section 11).
Binary consumer/provider Preserve the reference profile and node-owned ports; extend connectivity to
kernel role-labelled incidence occurrences and native hyperedges (Section 9).
Four FFI/RPC shapes Treat unary and streaming RPC as a bridge subset, not the complete universe
of port protocols (Section 22).
Graph, AST, and source Supported Blueprint source elaborates to an inspectable behavior graph. The
identity graph is not literally every arbitrary Kotlin AST, and generated
implementation is not a second manually edited authority (Section 5).
Flow-based determinism Push-exec/pull-data, Kahn networks, and synchronous dataflow are distinct
interpretations. Effects, state reads, bounds, and scheduling require their own
rules (Section 14).
113
Page 114
Extracted text for page 114
Reaktor: An Extensible Software Engine Technical preprint
Source tension Decision in this specification
All components as actors Use serialized ownership where state semantics require it. Pure operations
and supported stateless calls need not acquire mandatory mailboxes
(Sections 17, 22).
“Common/KMP” as a Common source sets, languages, execution domains, renderers, and
runtime deployment locations are separate axes (Section 4).
One update/security/UI Relate artifact, update, host-tree, runtime, and trust boundaries without
boundary assuming they coincide. Compatibility maps distinct revision counters;
compact slots are generation-local (Sections 22–27).
Automatic rollback Code rollback is allowed only when the current state and external-effect
contract permit it. Forward recovery can be necessary (Section 26).
Global data authority rule Default product profiles can be server-authoritative. Other profiles require an
explicit logical authority or merge algebra; no cache silently becomes
authoritative (Section 18).
Metadata as safety A capability label, signed bundle, actor type, or parameterized-query string is
not by itself an enforcement or isolation proof (Sections 20, 30).
GCP reference fleet Regional GCP/k3s cells are the documented reference architecture. The
generic provider model does not claim shipped support for every cloud
(Section 23).
Nexergy package The commerce/inventory/logistics and catalog/ledger/fulfillment
alternatives decompositions remain alternatives. Both illustrate reuse; neither is inferred
to be implemented (Section 33).
Server moderation and Server-readable processing and cryptographic server exclusion require
E2EE different product profiles. Their guarantees are not combined silently
(Section 20).
These choices retain the source corpus’s full-stack engine, composition, and tooling intent while
defining the stricter semantics used in this paper. Unsupported zero-overhead, universal determinism,
complete inference, and productivity claims from broad historical analyses are not adopted. They require
a defined model or an evaluation before becoming claims of the system.
114