Platforms, identity and polyglot execution
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: auth-analysis · reaktor-ffi · reaktor-surface · reaktor-work.
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
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
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.
Original page layout, starting at page 42
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
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.
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.
Original page layout, starting at page 43
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.
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.
Original page layout, starting at page 51
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.
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.
Original page layout, starting at page 53
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.
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.
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.
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.
Original page layout, starting at page 54
Source figure pages
Original figure page 55
