The engine and feature composition
Technical preprint, 16 September 2026 — web reading edition. This preserves the supplied paper’s content and its historical evidence boundary. Proposed interfaces, conditional propositions and constructed studies are not released APIs or deployment proof. Aligned equations, tables and listings retain their source layout. Source figure pages retain the original vector artwork. The accompanying finite model and coverage-map source package were not supplied; their reported results have not been independently reproduced here.
Current guides: reaktor-framework-overview · reaktor-service · reaktor-workbench-links.
The engine and feature composition · Graph model, protocols and computation · Platforms, identity and polyglot execution · Data authority, contracts and federation · Build, compilation and resource budgets · LiveUpdate, coordinator and human-agent authoring · Assurance and adoption studies · Precedents, evaluation and implementation sequence · References, notation, exercises and source lineage
Source title and abstract
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.
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.
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.
Original page layout, starting at page 2
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.
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.
Original page layout, starting at page 5
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,
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.
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.
Original page layout, starting at page 6
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:
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.
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.
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.
Original page layout, starting at page 8
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
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].
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.
Original page layout, starting at page 12
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.
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].
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.
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.
Original page layout, starting at page 14
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.
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.
Original page layout, starting at page 17
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.
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.
Original page layout, starting at page 18
Source figure pages
Original figure page 7
Original figure page 9
Original figure page 16
Original figure page 19
