Astra Reaktor Plan and Roadmap

Author: Astra / Codex. Planning baseline: 7 September 2026. Horizon: 7 September 2026–6 September 2027. First public v1: December 2026.

Turn an idea into a distinctive, working application—and keep increasing what it can do. Reaktor should become the standard way people and agents create, compose, understand, change and operate software. It competes directly in greenfield app creation with Emergent, Rork, Lovable, Bolt and similar builders, while also helping developers adopt and improve existing systems. Both paths lead into the same development engine.

Claude and Codex supply intelligence. Reaktor supplies reusable full-stack systems, product/design authoring, live preview, typed composition, runtime behavior, integrations, deployment and verification. A person can begin with an idea and a visual conversation; a developer can work directly in code. As the application grows, neither should have to abandon the project and rebuild it on a different foundation.

This page is the primary vision, core design, system map and execution plan. It incorporates the detailed core design brief and plans for two primary developers, each working with Codex and Claude. It refines the existing designs and chooses a delivery order; detailed specifications remain in the linked documents. It is a plan, not a declaration that the target architecture is implemented. Current-state statements refer to the local source survey on 7 September, including substantial uncommitted work. The complete internal evidence record is Astra Analysis, which requires authentication.

Reading paths: Product creation · Core design · Current status · Release scope · Two-developer roadmap.

1. The north star

Reaktor is the forge in which people and agents create, run and continually improve ambitious software. Its core product is a programmable development engine: reusable mechanisms, declarative composition, a live system model, specialized execution, and tools that understand the relationships between them.

The goal is to expand what one team can build while increasing confidence in each change. A founder starts with an idea and gets a distinctive functioning application. A developer adds custom behavior without falling out of the framework. A growing team can add native clients, asynchronous workflows, external systems, demanding compute and operational controls while preserving its source, product identity and data.

React demonstrated how a compact composition model can support a huge variety of interfaces. Unreal demonstrates the value of durable engine mechanisms, expressive authoring and a shared debugging model. Reaktor extends that ambition across clients, services, actors, data, infrastructure and AI. The destination is broader than a visual app builder or a game-engine analogy: an application can remain understandable, adaptable, testable and programmable throughout its life.

The launch must win both the first hour, when an idea becomes an attractive working app, and the hundredth change, when that app has real users and behavior worth preserving. Greenfield creation is a primary product. Existing-project adoption is another entrance into the same engine.

The central design improvement

Make one declared relationship useful in many places. A typed connection can determine wiring, generated clients, tracing and impact analysis. A capability requirement can determine implementation, fallback, placement and test scenarios. An actor's state ownership can determine scheduling, persistence, replay and update boundaries. A protocol can determine valid interactions, generated endpoints and failure monitors. A module's assumptions can determine whether a composition is admissible and what evidence it still needs.

This gives Reaktor two paths to growing power. Breadth comes from additional orthogonal mechanisms and integrations. Depth comes from making every existing mechanism participate in more of the development lifecycle. A new adapter should unlock existing features on another environment; a new checker should protect many applications; a better model should compose the same verified mechanisms more effectively. These effects can compound, but “exponential” is an ambition to measure rather than a mathematical guarantee.

A person should be able to ask the same project:

1. What should this product do, and what design expresses it?
2. What behavior is composed, where does state live, and what is running?
3. Which implementation is possible here, and how does the feature degrade?
4. What would a change affect across source, protocols, data and deployed clients?
5. Which assumptions, checks and measurements justify accepting the change?
6. What exact operation is authorized, and what happened when it ran?

The initial proving grounds are multi-user web products, native companion apps and workflow/AI products. BestBuds, Manna, GymBuddy and the surrounding applications exercise real seams. Later, scientific tools, device fleets, enterprise gateways and robotics coordination can use the same composition model with specialized execution profiles. Timing, safety and regulatory claims in those domains require their own implementations and evidence; adopting the graph alone does not establish them.

The two Reaktor essays provide the original thesis. This revision joins their strongest ideas and tightens their semantics. It preserves eight years of accumulated mechanisms and product experience, while replacing inconsistent boundaries incrementally. The core north-star design is in sections 6–15; the current implementation map and planned delivery order follow in sections 16–23.

2. The strategic bet and the standard of proof

AI can increase the rate at which software is proposed. Reaktor's bet is that the scarce capability becomes accepting, composing and operating those proposals with confidence. Better models should make Reaktor more valuable: each improvement in reasoning can use the same contracts, counterexamples, simulations and evidence interfaces without requiring the platform to replace its core.

The desired advantage is cumulative. A new app starts with substantial engine capability instead of regenerating authentication, state ownership, retries and platform glue from scratch. One typed contract should improve client generation, wiring diagnostics, authorization checks, impact analysis, simulation, deployment planning and agent context. A defect repaired in a reusable module should produce a regression obligation that protects every compatible consumer. An integration should bring its semantics and failure modes into the system model, rather than merely add a button to launch a tool.

“More powerful than comparable tools” is the objective, not a fact established by this document. Reaktor must win a measured combination of these outcomes. It should happily retain specialist tools that are better at their domain. A framework that forces users to abandon their best tools has increased its own surface area without necessarily increasing their power.

Overall design review: what to retain and what to improve

The existing work has an unusually valuable combination: live graph infrastructure, KMP/native/Worker reach, full product consumers, binary/native work, actor and capability patterns, visual authoring designs, and extensive tool integrations. The main opportunity is to make their boundaries agree. A broad collection of individually useful mechanisms becomes an engine when a feature can move through authoring, execution, simulation and change without losing its semantics.

The refinements below are normative target decisions. Where an older design implies transparent cross-process actors, universal zero-copy, unrestricted live mutation or whole-system correctness from graph metadata, use the more precise contract here. Historical documents remain linked as design history and implementation detail.

The improvements that should distinguish the engine

The decisive test is whether Reaktor can compose creation, adaptation, execution and change more effectively than isolated tools. Four integrated capabilities should become its signature:

• Executable product intent: acceptance journeys connect the user's goal to screens, domain behavior, capabilities and independently checked outcomes.
• Adaptive composition: the same feature can select a compatible local/native/remote implementation and an explicit fallback, with understandable consequences.
• Inspectable execution: fast compiled code remains connected to a live model of ownership, effects, state and causal observations.
• Reusable verification and optimization: a counterexample, profile or invariant becomes an asset that improves future changes and compatible consumers.

The core should improve several of these at once. A proposed abstraction earns inclusion by enabling new combinations, eliminating repeated glue, or making a relevant failure class decidable or enforceable. It should be tested against multiple application domains and an ablation that removes it. If it merely renames existing complexity, it has not increased Reaktor's power.

3. Greenfield creation is a first-class product

The first screen should offer Create an app as the primary action, with Open a project alongside it. Creation accepts a natural-language brief, sketches, design references or a starting recipe. It should not require understanding a graph, picking databases or completing an architecture questionnaire. The user can start quickly, while consequential product assumptions remain visible and easy to change.

The default creation workspace has a conversation with Claude/Codex, the running product preview, and a navigator for journeys, screens, data and behavior. Code, blueprint, tests and deployment are connected views with progressively deeper controls. A non-programmer works through intention and direct visual feedback; an engineer can edit source and inspect every abstraction. These are two depths of the same project, not separate products with an export cliff.

From an idea to an application

These are artifacts in a continuous session, not eight mandatory confirmation screens. Low-risk local generation and preview run under a bounded standing grant; the user can interrupt, branch, undo source changes or revisit assumptions. Credential use, paid provisioning, public publication and consequential data changes use the appropriate explicit boundary. The product should ask about user-visible decisions, not internal graph mechanics.

This promotes the existing New System Composer and scaffold-from-prompt design into the first public release. It extends them from skeleton generation to functioning behavior. A generated graph alone is not an app; a collection of screens with fake handlers is not a functioning product.

Full-stack features as the building material

The creator should compose tested capabilities at feature scale while retaining smaller primitives underneath. “Add sign-in” should connect the screen, identity flow, session lifecycle, backend verification, authorization policy and test fixture. “Add a discussion” should connect navigation, membership, storage, message lifecycle, notification intent and retry behavior. “Add an approval workflow” should include roles, legal transitions, persistence, audit and deadlines.

These are recipes over real module APIs, with replaceable UI and domain logic. The agent can specialize the composition instead of copying opaque templates or rewriting core security code. The recipe registry should declare compatible module versions, target support, assumptions, migrations, examples and tests. When a recipe is insufficient, ordinary code and lower-level graph primitives remain available; the platform must not silently force the product back into a template.

December needs a small set that spans varied apps: identity and roles; structured data and files; forms/list/detail/search; navigation and responsive layouts; one asynchronous workflow/notification path; an integration boundary; and an optional typed AI call. Advanced payments, collaborative editing, media processing, complex offline sync and regulated-domain guarantees need separately qualified adapters. The product should show what is supported, what is generated custom code and what still needs configuration.

Design quality belongs on the critical path

Reaktor should generate products with their own visual identity. Machine Signal is the Studio's design system, not a mandatory look for every generated application. Human Signal is a BestBuds reference, not a universal template. App-specific tokens, density, typography, accessibility, platform conventions and motion should derive from the brief and references.

The author should be able to select a component in the preview and change its appearance or behavior through direct controls, conversation or code. Selection resolves to a stable screen/component/source identity. A visual edit should preserve bindings and behavior; a logic edit should preserve unrelated styling. Changing a token should show affected screens and visual checks. Reference artwork or a .pen scene is design input, not executable proof of the app.

Preview must cover loading, empty, error, denied, offline and successful states. It should run the same application modules as the release lane wherever supported. Simulated integrations are useful during creation, but a “Connect service” gap must remain visible until a real binding is tested. Browser emulation is not evidence that a native app's permissions, background work or signing path works.

Build apps that can outgrow their first prompt

The creator must handle follow-up changes that cut across layers: add organizations to a single-user app; change a field without losing data; introduce an approval step; add a mobile client; replace a model provider; split a heavy service into another runtime; or add an external system with weaker guarantees. The engine should explain the impact, generate the migration or adapter, and exercise the affected journeys.

Code ownership is practical: normal Git history, readable source, documented build commands, portable data export and the ability to continue in an IDE or with Claude/Codex directly. Reaktor should remain useful after that move, through its runtime modules and project model. Retention should come from continuing value, not making the project impossible to leave.

4. The engine behind creation

The creation product needs a real application-production pipeline, in addition to the semantic kernel. It should turn a brief into a buildable project and keep the artifacts synchronized through subsequent changes.

Project session: retain the brief, accepted decisions, source revision, design assets, module lockfile, environment, pending changes, preview and evidence. Long agent runs must survive disconnects and be resumable or cancellable. Changing the brief invalidates the affected work rather than launching a full rebuild by default.

Planning and generation: decompose work into executable slices with shared contracts and explicit source ownership. Let Claude/Codex specialize the product, reuse engine modules and implement custom code. Parallel agents can work on disjoint slices; the coordinator integrates through versioned source/semantic checks. A second agent's agreement is useful review, not a correctness certificate.

Workspace execution: isolate each project's filesystem, processes, network policy, secrets, build cache and preview origin. The public browser creator needs a managed execution lane; advanced users also need a local companion using the same protocol. Choose one runner implementation for December, with durable job status, quotas, cancellation, cleanup and artifact retention. Do not let generated code run inside the control-plane process or inherit its provider credentials.

Fast feedback: use published/prebuilt framework artifacts, warm toolchains, compatible recipe caches and impacted-scope checks. A browser user should not wait for a fresh native toolchain bootstrap to see the first web screen. Kotlin/JVM, Worker and native target builds can have different schedules while sharing contracts. Cached evidence must include the source, compiler, dependency, policy and adapter inputs that make it applicable.

Target capabilities: express product requirements independently of platform names, then choose an implementation and fallback for each target. A feature can use native hardware, portable code, a remote service or an explicit unavailable state. The creator sees the product consequence—such as background updates stopping or offline capture remaining available—and the engine generates and tests the selected strategy. Shared contracts preserve meaning while UX, permissions and execution remain platform-specific.

Provisioning and preview: maintain separate disposable preview and production environments. Bind data/auth/files through the selected recipe, create safe test identities/data, expose an access-controlled preview, and retain the exact revision running there. Offer a simple managed deploy path plus an export/self-host path. Hide routine infrastructure plumbing while showing costs, data location and consequential choices when they matter.

Product feedback: map bug reports and selected preview elements back to the journey, source, state and relevant trace. Model/evaluation cost, build failures and repeated repair attempts should be visible enough to stop wasteful loops. Improve recipes and checks from explicit user feedback and anonymized or consented examples; private customer source and data must not silently become shared templates or evaluation fixtures.

These are proposed systems with their own status and release gates. The current Reaktor web prototype is not an implemented hosted app factory. The existing framework, Gradle tooling, supervised executor, auth, source maps and product integrations reduce the work, but isolation, resumable build sessions, creation orchestration and browser UX still require implementation.

5. Competing with builders and learning from infrastructure

App builders and agent development environments already set a substantial bar. The following capabilities were checked against official documentation on 7 September 2026; they are vendor-documented features, not independently measured success rates. Reaktor's proposed response is an ambition to test, not a claim that competitors cannot support complex applications.

Reaktor should not base its positioning on “others only generate toy screens,” “only Reaktor has testing,” or “only Reaktor supports native apps.” It must match their useful defaults and then show that a richer engine makes more ambitious products easier to create and maintain. The winning comparison spans initial design quality, working behavior, cost, speed, source portability and the twentieth meaningful change.

The framework landscape is complementary. Encore already derives application structure from code for tooling and infrastructure; Temporal provides durable execution; Dapr provides portable distributed building blocks; Aspire models resources and their lifecycle. Reaktor should integrate or learn from these mechanisms where useful, while developing its full client-to-runtime creation model. MCP and OpenTelemetry are interoperability foundations, not competing application builders.

Claude and Codex are enabling partners throughout. The aim is to make their work more effective inside Reaktor and make Reaktor projects equally usable from their ordinary development environments.

6. The core: a live model with a small semantic kernel

Reaktor has one heterogeneous, nested, multilayer logical port graph living through source authoring, build and runtime. Definitions describe the system; activations execute its supported regions; observations report concrete executions; derived views help developers and agents change it. These are connected entities and interpretations in one identity fabric, with distinct owners, revisions and evidence. The Living Graph foundation is the canonical specification; the atlas shows its authoring, query, boundary, trace and change instruments.

Target architecture. These are architectural responsibilities and relationships, not a claim that all components are implemented.

A small nucleus and extensible domain semantics

The semantic kernel owns finite data and pure laws for identity, contracts/endpoints, typed relations, containment, versioned facets, snapshots, normalization, validation and patches. It does not own UI layout, payment rules, SQL execution, model inference or cloud APIs.

A module attaches domain facets and implements named semantic interfaces: owns state, declares effects, requires capabilities, provides a protocol, supports migration, maps to source or describes cost. Generic analyses use these interfaces instead of a growing switch over every component class. Unknown optional metadata can be preserved; an unknown facet required for correct activation produces an unsupported-contract finding. This borrows the extensibility principle of MLIR interfaces without requiring an MLIR dependency.

Module validators and optimizers remain executable extensions with their own trust and test boundary. They can contribute obligations and evidence; they cannot replace fundamental structural checks or grant authority by returning success. The trusted base for a particular claim includes the relevant checker, host, adapter and enforcement path—not just the size of the core package.

The kernel exposes definition identity separately from its revision/content digest. A runtime instance adds activation identity and epoch. An observation adds its source, sequence, time and coverage. Operation, conversation, actor and artifact IDs join those records without being conflated with trace IDs or source-file names. Reflected Kotlin class names and runtime object addresses are local implementation details.

Four linked semantic domains

These domains are typed facets/relations and owned records in one logical graph, not four parallel graph stores. “One model” means common identities, mappings and laws. Source still owns algorithms; a design system owns its tokens; a database owns domain records; a deployment controller owns applied resources. The graph records their relationships and each field's authority. It is not a new database that silently takes ownership of everything it can display.

Relations carry a type: containment, dependency, invocation, data flow, navigation, supervision, state ownership, authority, placement or derivation. Canonical dependencies explicitly name consumer and provider. A data-flow view may draw values in the other direction, using an explicit projection. This resolves the directional ambiguity in earlier designs.

Scope, semantic layers, detail, revision/time and editor mode vary independently. A composable ordered layer/query stack can combine structure, contracts, state/effects, runtime, authority, navigation, data/analytics, placement/delivery and an agent proposal. Folding preserves exact endpoint identities; layout does not change execution. Source and trace editors can pin different revisions without losing their correspondence.

The target interaction is continuous semantic zoom, like moving from Earth to cities and streets: whole application/fleet → runtime island → feature → node → port. Scale bands change detail over the same graph while stable IDs, selected routes, layers and time remain pinned. Scope independently controls query/budget rather than forcing another page. Inspecting a DOM/Compose element highlights its source, bindings/handlers and full operation/state/effect/resource route; reverse navigation reveals the UI affected by a state or service change. Named capture, send, return, notification and analytics routes can be composed, simulated and executed through selected profiles, with per-target run/resume/drain/reconciliation controls. See continuous zoom and UI-to-system mapping.

Orchestration is trigger-independent and headless flows are first-class. A typed entry/admission registry accepts UI events, HTTP/service/webhooks, queues/Pub/Sub/state changes, schedules/timers, device streams, CLI/operators, agents through MCP/A2A adapters and lifecycle/protocol continuations. It preserves schema mapping, event/correlation identity, acknowledgement, ordering/backpressure and effective grants. A versioned flow/runbook can join running protocols or streams and produce multiple outcomes; it need not begin at a UI or terminate as a finite DAG. ETL, settlement, incident response, fleet coordination, deployment/migration and native scientific pipelines use the same graph and profile-aware commands. See flow entry and admission contracts.

Local runtime islands and a federated live view

An island is a lifecycle and mutation boundary controlled by one host: an app process, JVM service, Worker invocation/host profile, Durable Object or native runtime. It owns local activation handles and publishes an authorized structural/observation projection. External systems join through adapters that state coverage and write ownership.

Federated queries identify their consistency: a local atomic revision, a vector of source revisions and observation times, or a coordinated causal capture. A disconnected host becomes stale or unknown. Subscription records carry epoch, sequence and resume cursor; missing events trigger resnapshot or an incomplete result. There is no implied instantaneous global graph transaction.

The model describes stores, schemas, computation kernels and selected entities without turning every database row, pixel or tensor element into an always-live node. Queries are scoped and budgeted. This lets very large systems stay inspectable while retaining domain-appropriate storage and execution.

Ordinary Kotlin and Kotlin DSLs retain general loops, recursion, libraries and custom algorithms. The general Kotlin/behavior profile is required to be Turing-complete in the usual unbounded-memory language model; actual targets retain finite resources and execution budgets. Explicitly reified regions provide additional visual syntax and stronger checks under named computation profiles. Actor, stream, durable-protocol, pure-value, general-code and native profiles have different cycle, state and failure laws; the system is not globally a DAG. Source adapters state which edits round-trip, and opaque bodies remain source-editable without a false claim of complete extraction.

Keep the graph alive while specializing execution

Compile stable wiring into direct references or generated calls. Fuse a hot sequence of pure operations when its observable contract permits it. Keep the semantic identity/source mapping and opt-in probes associated with the compiled region. Retain indirection only where it earns value: dynamic binding, policy mediation, instrumentation or an explicitly updateable boundary.

This creates a fast execution path and a live descriptive/control path over the same declared program. A trace can explain a fused region without dispatching every arithmetic operation through a graph map. A dynamic region pays a measured boundary cost; a static native kernel need not. Optimizations must preserve the required behavior, ownership and observability contract and identify any reduced inspection granularity.

The useful Unreal lesson is the division between durable mechanisms and expressive behavior authoring. Blueprint does not universally disappear into native code: Epic documents its virtual-machine execution and different performance characteristics. Reaktor should make its own static/dynamic tradeoffs explicit. Epic's Blueprint/C++ guidance.

Visitors become reusable analyses and transformations

Keep visitors as pure traversal/query logic over authorized immutable inputs. Build a pass system around them that distinguishes proposals from runtime operations:

Observe, Install and Execute are sibling mechanisms, not permission for an analysis visitor to mutate a live Graph. Environmental IO is collected into explicit input artifacts. Unrestricted Kotlin callbacks cannot be assumed pure merely because an interface is read-only.

Traversal specifies relation kinds, boundary rules, deterministic order, cycle behavior, cancellation/budget and visit multiplicity: once per entity, once per edge or per relevant path/state. For example, a service reachable through both guarded and unguarded routes is not protected merely because a visit-once traversal saw the guarded path first. Authorization analysis must propagate relevant path state or solve a suitable fixed point. BFS must not silently promise DFS postorder callbacks.

A pass declares required semantic interfaces, input dependencies, result schema, version and preserved analyses. Incremental results must equal a fresh analysis at the same complete input or be invalidated. Lost events, changed policy or an unknown external dependency cannot yield a reused green result. Independent read-only passes can run in parallel; concurrent rewrites need semantic conflict detection. MLIR pass infrastructure is a useful precedent for analysis/transform separation and conservative invalidation.

Graph transformations acquire explicit laws

A rewrite identifies whether it preserves representation, preserves behavior under assumptions, changes product intent or adapts execution within an allowed degradation contract. It returns its patch, source mapping, affected state/effects, preconditions and required checks.

The small core laws are executable: rejected patches leave published definitions unchanged; an accepted non-noop patch publishes one valid new revision; readers see a complete old or new definition; equal complete planning inputs produce the same plan; a transformation cannot enlarge authority without a separate grant. Runtime activation and external effects have additional laws in section 9.

This turns visitors into a route to much more powerful tooling. A telemetry pass can propose lifecycle-owned probes with cost/data budgets. An auth pass can identify and mediate every declared entry/effect boundary, including future activations. A deployment pass can derive cross-host obligations. An optimization pass can suggest caching, retries, batching or relocation—but must account for freshness, principal scope, duplicated effects and changed failure semantics. Adding a wrapper is not automatically behavior-preserving.

See graph-kernel analysis, visitor design, Stable Foundations, Living Graph foundation and mega-scale strategy. Migrate through adapters from the current runtime/editor models, one real feature at a time.

7. Kotlin and the public programming model

Reaktor should become the framework that reveals the full reach of Kotlin: one language for reusable domain mechanisms, declarative architecture, concurrency, native clients, backend code, build tooling and generated interfaces. This is an ecosystem ambition, not a claim of endorsement or exclusive suitability. TypeScript and C++ remain first-class authoring and implementation languages; using a Reaktor module from either must not require becoming a Kotlin build expert.

Why Kotlin is the center

Kotlin fits this particular design because several capabilities meet in one toolchain. Multiplatform compilation lets the same pure contracts and behavior target different runtimes. Interfaces, extension functions and DSLs make small composition APIs expressive. Coroutines provide a common way to describe suspended operations, cancellation and streams. Platform source sets and expect/actual give native differences explicit homes. JVM libraries, native interop and JavaScript access bring large existing ecosystems into reach. Platform and UI support still have their own maturity levels. Kotlin platform support, coroutines.

The design consequence is share meaning, specialize execution. Share contracts, state transitions, protocol definitions and pure calculations where their semantics agree. Specialize UI conventions, schedulers, storage, binary layouts and device behavior where they differ. A coroutine scope helps express lifetime; it does not automatically make a database transaction durable or make shared actor state isolated.

Compiler integration should extract declared structure and generate efficient glue, so users do less bookkeeping and the runtime does less reflection. Start with the current KSP/FlexCoder foundation for declarations, codecs, manifests and source maps. Use a separate, optional compiler analysis for expression-level effect restrictions and lowering of the owned behavior language. KSP cannot inspect statements or expressions; Kotlin's custom compiler plugin API has an ongoing compatibility cost. Keep Reaktor's portable IR and public contracts independent of compiler internals, pin tested compiler versions, and retain explicit declarations as an escape hatch. KSP scope, compiler plugin guidance.

The year-one language roles are deliberate:

This prioritizes additional expressive reach without closing the ecosystem. Rust's ownership tools, Swift's native APIs or Go's deployment characteristics can matter to particular consumers even when Reaktor does not build a complete parallel SDK for each at launch.

Two entrances, one set of mechanisms

Create assembles a new app from intent, design and full-stack modules; Adopt adds useful capabilities to an existing project. Both use the same contracts and runtime. Auth, services, storage and notifications must also work as ordinary libraries. Graph composition adds lifecycle, inspection and cross-module checks; mediated effects and explicit protocols add stronger guarantees.

This table describes adoption in existing code. Greenfield onboarding starts with the product creation workspace, which supplies appropriate defaults.

Declarative architecture with ordinary code inside

Keep the familiar roles and make their interactions explicit. A repository exposes domain data access and its consistency contract. An interactor implements a use case through declared dependencies. An actor owns serialized state transitions where that ownership is useful. An adapter implements an external or platform boundary. A UI renderer projects product state into React, Compose or another declared surface. A feature composes these roles; none needs to become a mandatory wrapper around every function.

Algorithms remain Kotlin, TypeScript, C++ or Python. Blueprint authoring owns the composition and selected behavior program: typed events, values, branching, bounded iteration, functions, state transitions and effect requests. Flow-based programming gives explicit channels and scheduling; ordinary control-flow nodes remain available where a data-flow representation would be awkward. Cycles declare delay, state or scheduling semantics, so a visual loop does not accidentally become an unbounded synchronous call chain.

React and Compose supply a useful law for architecture too: declaration should describe the desired structure; a reconciler computes the change. An architecture declaration must not perform arbitrary effects every time it is evaluated. Resource acquisition belongs to prepared activation; data mutation belongs to an explicit operation. This makes repeated evaluation, preview and rollback of source changes tractable.

Source and visual authoring round-trip only where ownership is defined. Reaktor-owned composition has an editable projection; ordinary source exposes editable declared regions or a read-only map. Every generated node retains its source identity. Both directions detect stale edits and ownership conflicts, preserve unrelated code/comments, and report drift. A new authoring surface must consume the shared parser, normalizer and validator rather than invent another graph language.

December delivers a small useful subset with a clear extension path. The long-term authoring ceiling includes deeply nested heterogeneous flows, choreography, state machines, domain-specific editors and code islands in the same project. See Framework Overview, Core, Service, React/Compose and Visual Language.

8. A generating basis: modules, features and capabilities

The eigenvector analogy captures an excellent design objective: find mechanisms with little redundant meaning that combine into a large useful space of systems. The precise engineering metaphor is a generating basis, not literal linear algebra. Software composition has state, ordering, constraints and nonlinear interactions; “fractional combination” should mean specialization, selective use and substitution rather than undefined arithmetic on modules.

Separate structural vocabulary, behavior and product recipes

Value, State, Stream, Request and Mailbox are useful public interaction shapes. Their contracts must additionally state ownership, lifetime, errors, ordering, consistency, cancellation and delivery. A state view is not permission to mutate its owner's storage. A Flow is not a durable queue. Actors are a strong choice for serialized long-lived behavior, while a small UI value can use a cheaper owned state scope.

Use a small set of composition operations:

The compiler should discharge straightforward obligations automatically and expose the rest as useful findings. Application developers work with features; mechanism authors define the laws that make those features composable.

A module carries its operating contract

A module package should include namespaced contracts/schema versions, implementation/source digests, supported runtime profiles, state ownership/schema, effects, capability requirements, policy hooks, migrations, cost/budget hints, probes, fixtures and evidence references. Its ordinary API and opt-in graph projection share behavior and tests; the graph wrapper must not reimplement the business logic.

Assumptions and guarantees make modules compose usefully. A retry mechanism can require idempotency; an actor can require exclusive transition ownership; an auth boundary can require a verified principal. The checker establishes that the selected composition discharges those requirements on the paths where the guarantee is claimed. Compatible module proofs/tests do not invent unstated product requirements.

Introduce a new primitive only when it adds expressive reach, a meaningful law or a large reduction in repeated glue. Require at least two credible consumers, a small example and a counterexample it prevents. Compare with a recipe built from existing mechanisms. Maintain a domain matrix—social/realtime, approval, offline capture, AI tools, native media and existing-service adoption—and measure manual glue, concepts learned and generated-code churn. Remove or merge abstractions whose distinct names do not create distinct useful behavior.

Feature-capability becomes an adaptive composition system

Keep adapters and capability subinterfaces: a camera adapter can expose capture, front/back selection or streaming without branching on platform names. Improve the design by separating six facts:

1. Installed adapter: which implementation exists in this host/session?
2. Capability offer: what operations and guarantees can it provide?
3. Environment observation: what is known about network, storage, power or resource availability?
4. Permission: has the OS/user granted the privileged operation?
5. Authority: may this principal act on this tenant/resource now?
6. Strategy: which eligible composition satisfies the product's requirements?

Plain APIs can retain nullable adapters for basic availability. Modeled features need a structured reason for unavailable, denied, unsupported, stale or unknown states. A single Full/Standard/Basic tier cannot express all relevant differences: an in-app badge does not satisfy a requirement to alert someone whose app is closed.

A feature declares hard requirements, preferences and permitted fallback transitions. Offers describe dimensions such as privacy/residency, persistence, timing, quality, hardware, execution mode, latency/cost and authority. Resolve hard constraints first; rank eligible choices with a versioned policy. If none qualify, return a useful unsatisfied requirement or an explicitly permitted degraded mode. Preserve human choice where alternatives change product meaning.

A capability plan records the request, selected implementation/profile, rejected alternatives and reasons, environment/permission/policy snapshot, grants, validity/recheck conditions, product consequence and migration of already-active work. Begin with an explainable rule-based resolver; add a solver or learned ranking only when the decision space needs it. Failure of a heuristic is not proof that no valid composition exists.

Graceful degradation is executable product behavior

For field capture, a feature may require that an attachment remain private and eventually reach its owner. A native camera is preferred; browser upload can satisfy the same product outcome; queued local intent can preserve capture while offline. Sending the file to an unapproved remote processor is not an eligible performance fallback. An absent adapter produces a clear unavailable action or a designed alternative.

For reminders, a requirement to notify outside the app can select an authorized push/server route. A badge is a valid alternative only if the product explicitly accepts that weaker behavior. Rebinding an accepted reminder preserves its operation identity and transfers effect ownership through the declared completion protocol. Provider idempotency or reconciliation must resolve an already-dispatched attempt before an alternative can safely run; identity alone does not prevent duplicate delivery.

Recheck changing permissions and grants at effect time. Use hysteresis, minimum dwell and measured switching cost for optional performance/quality changes; revocation can demand immediate cessation. Distinguish plans for future operations from migration of active ones. This same mechanism can later select C++ acceleration, local/remote Python work, model providers, rendering strategies or actor hosts.

Replace global Feature access in modeled code with a host/session-scoped context that owns installed services, task lifetime, clocks, randomness and effect handles. Keep the current global facade temporarily for explicit legacy contexts. Tenant/account/session state must never be silently inherited from a process-wide registry.

A new headset or device category can unlock existing features by satisfying these capability contracts. Platform-specific UX, permissions, performance and conformance still need validation. December should prove two bounded strategy families on real web/native paths; the general optimization space grows from those fixtures.

See capability design, Core, notifications and modules/architecture overview. By year end, publish the module/recipe contract and local installation path; by the first anniversary, an independent maintainer should use the same conformance kit.

9. Runtime, actors and safe live evolution

The runtime interprets a validated composition through named host profiles. Its central responsibilities are resource lifetime, state ownership, communication, effects and change. These responsibilities should be independently useful as libraries and composable through the graph.

Declaration, preparation, publication and reconciliation

Keep graph construction ergonomic, but have modeled builders produce finite declarations and a deterministic binding plan before effects begin. Provider selection has explicit precedence and ambiguity errors. Navigation/UI behavior is an optional feature of a runtime scope, not an unavoidable dependency of every headless graph.

An operation names the state it changes: an authored/desired definition revision, a local active topology/epoch, or externally reconciled resources. Committing a valid desired definition does not establish that it is active everywhere.

For a supported local activation, validate the entire plan, prepare owned resources, and publish complete bindings at an explicit commit point. A preparation failure disposes of prepared resources and leaves the prior active topology intact. Arbitrary provisioning is not hidden inside this local atomicity claim; remote resources use explicit effect/reconciliation steps. Readers must never see half-wired local structure as a successful activation.

Lifecycle scopes own tasks, adapters, subscriptions and children. Close has a deadline and observable disposition; cancellation propagates through the declared tree. No stopped parent should retain an untracked child executor or telemetry subscription. Compatibility wrappers around current mutable Graph/PortGraph remain while individual features move to this boundary.

Actors own decisions, not merely a dispatcher

The modeled actor form is a bounded, non-suspending transition from state, message and admitted facts to next state, replies, effect intents and timer changes. The runtime alone publishes the next state. Inputs and published state must be immutable or defensively isolated; a handler cannot mutate already-published state or captured external objects before commit. Effects run outside the turn and return completion/failure messages carrying operation and activation/session identity.

Restricted profiles enforce turn budgets through supported constructs and checkpoints. A timeout alone cannot terminate arbitrary Kotlin/native work; a hard termination guarantee needs a host that can enforce it, including isolation where required. Unrestricted handlers retain an explicit weaker profile.

This makes asynchronous work composable without allowing its callback to mutate a new session or bypass the mailbox. A long request becomes an operation state machine; it does not hold the actor's mailbox while waiting for an external service. Read-only queries expose immutable snapshots with a version. Synchronous self-requests and request cycles produce a diagnostic or use explicit continuation messages.

The current Channel loop is a useful starting point, but limited parallelism and serialized receive calls are not heap isolation or a guarantee about arbitrary launched coroutines. Default to non-reentrant state mutation; support special reentrant or legacy suspend profiles only with declared limitations and tests. Orleans scheduling is a useful reference for the distinction between task serialization and request interleaving.

A logical actor identity includes application, environment, tenant, actor type and entity key. State/message schemas and implementation revisions are versioned separately. An activation has a host/incarnation/epoch. Display names, sanitized file paths and KClass identities cannot define durable ownership.

Durable Objects and a JVM/Postgres host can implement named durable profiles. They are not transparently equivalent destinations for arbitrary local ActorNode code. Native dependencies, transaction scope, interleaving, data location and resource limits constrain placement.

Admission, deadlines and message outcomes

Every request has a stable message/operation identity, payload/schema identity, destination, deadline and scoped caller provenance. Admission and business completion are separate observations. The deadline includes time waiting to enter the mailbox. Capacity is bounded in messages and bytes with tenant fairness.

Messages can be rejected before acceptance, accepted, processing, completed, domain-rejected, failed, cancelled before a defined commit, or unresolved with an unknown outcome. Durable retries retain the same logical operation and record separate attempts. Dropping/coalescing is appropriate for explicitly lossy signals such as progress; it is not valid for an accepted durable command.

Concurrent producers have no inherent global order. The actor defines a committed turn sequence and preserves any promised producer/conversation causality. Shutdown drains, persists or rejects work according to its profile and resolves pending local asks. Poison messages, domain errors, transient adapter failures and runtime invariant failures need different supervision policies. Runtime cancellation must not be swallowed as an ordinary restartable error.

Durable state and effect completion

Within one transactional authority, commit inbox disposition, state version, reply result, durable timer changes and outbox intents together. A unique operation key plus payload digest distinguishes a safe duplicate from a conflicting request. Deduplication retention is part of the supported retry/replay window.

External calls happen after commit. Each effect chooses an explicit completion strategy:

An outbox prevents lost intent; it does not alone prevent duplication at an arbitrary external provider. Compensation is a new domain operation with its own possible failures.

Cancellation before a commit can prevent that commit when the boundary supports it. After an external dispatch, cancellation can stop future work while the sent operation may still complete. Cancelling a caller's wait and cancelling a business operation are different actions. Preserve OutcomeUnknown when the system cannot yet establish the result.

Supervision, passivation and placement

A restart creates a new activation and rebuilds owned resources. A durable restart restores the last committed state; a local restart follows its explicit initial/retained-state policy. Durable passivation closes the active route, finishes or records the current turn, persists timers/outbox state and releases resources. A durable inbox may continue accepting work for reactivation; a local mailbox follows its explicit close policy.

Migration transfers a versioned state/protocol/inbox/outbox/timer checkpoint and advances a fenced ownership epoch through the authoritative store. Heartbeats, discovery or Kubernetes readiness are not state ownership. Stale owners must be rejected where state commits occur; already-dispatched external effects still need their own idempotency or reconciliation.

Use managed DO placement or a simple qualified store-backed host before inventing a cluster coordinator, gossip protocol and consensus layer. Cross-provider or multi-region movement is a migration with explicit assumptions. Scale actors where independent state keys justify it, and keep ordinary pure functions and bulk processing outside unnecessary mailbox overhead.

Marked graph regions and code push

Live evolution has four distinct modes: development reload, configuration/topology reconfiguration, implementation/state migration, and distributed rollout. Support them separately so a fast development loop does not imply arbitrary production replacement.

An updateable region declares stable exported contracts, allowed host capabilities/effects, resource budgets, state schema, protocol version, in-flight-work policy and rollback/roll-forward class. Pure/static code can be replaced more easily than a stateful actor or a protocol participant. Unsafely captured native pointers, host objects and mutable closures cannot cross epochs as if they were portable state.

The intended Kotlin/JS + Hermes + FFI update lane is:

1. Build a versioned bundle for an exact supported host/engine contract; retain source maps, module locks and provenance.
2. Validate signature, target/policy eligibility, imports/exports, grants, limits and state/protocol compatibility.
3. Instantiate in a separate owned realm/activation; run fixtures and side-effect-free or explicitly isolated probes.
4. Drain or version-route in-flight work at the marked boundary; checkpoint and stage a validated state migration without exposing partially migrated active state.
5. Compare the expected prior epoch and atomically publish the new routing and state ownership within the declared activation domain; route new calls to it and handle old completions by the chosen policy. A migration requiring external commits uses its separate reconciliation protocol.
6. Reconcile health, retain a receipt, and use the declared rollback or roll-forward procedure.

Shadow execution cannot freely duplicate external effects. A bundle's signature establishes provenance, not correctness; a failed health check cannot reverse an email, payment or incompatible schema migration. Distribution permissions and store policy remain independent of technical host capability, as detailed in section 13.

December makes the ordinary edit/build/preview reload loop strong and admits only bounded topology/configuration change; it does not promise the full Hermes module-replacement pipeline. The year-one advanced update experiment should start with stateless marked logic and compatible host APIs, then earn stateful replacement through migration and failure evidence. This is a route to controlled live programmability, not a reason to postpone creating real apps.

See lifecycle, actor model, distributed actors, graph migration and FFI design.

10. Formal methods and simulation as everyday development tools

Reaktor's opportunity is to make verification reusable at the same level as composition. A module can bring its own invariants and failure fixtures; a graph can expose the assumptions joining modules; a compiler can report a counterexample; an agent can repair against that concrete obligation. Most users should experience this as better diagnostics and dependable behavior, not a requirement to become verification researchers.

Match the method to the claim

These methods are complementary. There is no total ladder in which a proof about a model automatically outranks missing implementation coverage. Declarations describe intent; static analysis constrains an analyzed program; runtime mediation enforces controlled effects; isolation contains untrusted execution; evidence records what was established.

An effect annotation or a ModeledNode marker cannot prevent arbitrary Kotlin/C++ code from performing IO or mutating captured state. Strong profiles need restricted construction/APIs, source/build checks, mediated handles and real process/host isolation when appropriate. An opaque module remains useful. Only claims that depend on its unproven behavior inherit that assumption; unrelated structural facts remain valid.

A practical chain from specification to runtime

Start with small executable laws and a finite obligation registry. Use graph constraints to reject invalid compositions. Use a bounded protocol model to generate legal and failing traces. Replay those traces through the actual runtime and adapter harness. Keep independent/reference implementations where bugs in a generated checker and generated implementation could otherwise agree.

TLA+/Quint suit temporal and failure interleavings; Alloy can explore finite structural counterexamples; Lean can establish selected pure preservation laws once the model is stable. Choose the smallest useful portfolio rather than make every tool a launch dependency. Conformance is the bridge from model results to shipped code. Quint documentation, Formal Methods design.

A finding identifies the violated property, minimal relevant graph/trace, source locations, selected contracts/profiles, assumptions/bounds, tool versions, revision and reproduction command. It distinguishes failed, unknown, incomplete, stale and inapplicable evidence. An agent should be able to repair the exact failure without guessing what a red badge means.

Useful core obligations include path-sensitive authority reachability; deterministic wiring and atomic local publication; no stale-epoch state mutation; accepted-message disposition; non-amplifying authority; sound capability selection; incremental/full-analysis agreement; and source/contract correspondence. Counterexamples such as “retry repeats a charge” or “revoked camera permission is cached as granted” should become reusable regression assets.

Deterministic scenarios over the actual composition

Inject time, randomness, scheduling decisions and effect outcomes through explicit host interfaces. The same declared composition can then run under production adapters or a scenario interpreter with virtual time, seeded failures and controlled delivery. Record operation IDs, message order, state revisions and effect completions so a failure can be minimized and replayed.

The long-term target is a multi-runtime simulation that preserves protocol and domain semantics while virtualizing hosts. Native compute can run through a qualified deterministic implementation, an independent oracle or an explicitly abstracted boundary. Uncontrolled clocks, external models and opaque device behavior prevent complete deterministic replay; record their inputs/results or show that coverage is absent. Simulation fidelity must be tested against real targets.

Make counterfactual exploration a normal product feature: change the network, revoke a grant, slow a consumer, duplicate an event, restart an actor or replace a module, then inspect the affected journey. Performance visitors can compare placements and batching strategies inside that scenario, followed by real profiling before promotion.

Evidence composes and expires with its assumptions

An assurance record binds claim, scope, method, result, assumptions, bounds, source/artifact/toolchain/profile digests, coverage, provenance and freshness. Its dependency graph identifies which changed inputs invalidate it. A result for an old module or policy must not silently attach to a new activation.

Module guarantees hold when their assumptions are discharged in the actual composition and the supporting enforcement/conformance boundary exists. A typed valid app can still implement the wrong product requirement; independent product acceptance remains necessary.

December needs real structural/authority checks, named kernel/concurrency regressions, one bounded failure model tied to runtime tests, and a shared finding format. Broader choreography proofs, optimizer equivalence and stateful-update verification follow working semantics and consumer demand. See Formal Methods and Verified Foundations.

11. Claude, Codex and an agent-native system interface

Reaktor should give an agent a semantic development environment: the relevant program, available operations, constraints, counterexamples and measured outcomes. Claude and Codex provide planning and generation. Reaktor makes their proposals easier to ground, compose, check and execute, and keeps those benefits when models improve or change.

A richer interface than isolated tool calls

MCP is a distribution interface for tools and context. A2A is an interoperability interface for agent tasks and artifacts. Under both, Reaktor should expose its own versioned domain protocol: scoped snapshots, queries/subscriptions, typed proposals, validation findings, change plans, execution handles, cancellation and receipts. A client that only supports ordinary MCP still gets useful tools; a richer client can subscribe to a changing graph slice and negotiate typed capabilities without a new natural-language explanation for every step.

An A2A task maps to a Reaktor mission/run, artifacts map to versioned source/evidence/proposals, and status updates map to run events. Task completion does not confer deployment authority. Agent cards and advertised skills help discovery; local policy decides which operations and data are accessible. Pin and test protocol versions and optional capabilities rather than treating a protocol logo as compatibility. A2A specification.

The common interaction is discover → query an authorized snapshot → receive a scoped context packet → propose → normalize/check → repair from findings → prepare an exact plan → execute under the required authority → observe/reconcile → retain a receipt. CLI, IDEs, Studio, MCP and A2A must use the same operation contracts. The existing read-only MCP tools are a starting point, not the full execution broker.

Make each unit of context do more work

A context packet should include selected entities/revisions, owners, relevant source spans, contracts, capability choices, dependency and impact slices, protocol obligations, recent traces, verification results and unknowns. A query records why each item was included. Authorization is applied before disclosure, including to graph metadata and logs. Size/time budgets and incremental updates let the agent maintain a useful working set across long projects.

The next improvement is obligation-directed development. A requested feature becomes product journeys and a typed change plan. The checker turns unresolved requirements into specific obligations: a missing provider, a forbidden effect path, a state migration, a protocol branch or a platform fallback. Claude/Codex implement those pieces, and the engine determines which obligations are now discharged. The model still exercises judgment; the machine-checkable portion of acceptance becomes stable and reusable.

Parallel agents work on explicit source/semantic scopes against a common base revision. Their proposals carry dependency read sets, changed owners and affected obligations. Independent changes can merge; conflicting assumptions require revalidation or human resolution. Budgeted child runs inherit narrower authority and return artifacts, never ambient production credentials. A second model's approval remains review evidence, not a correctness proof.

Acceleration that compounds across model generations

Each successful change should leave a reusable asset: a lawful module, better recipe, counterexample, migration, adapter, diagnostic or conformance test. Each failure should reduce repeated work by improving a check or exposing a missing assumption. Reaktor's accumulated value is the amount of difficult behavior its users no longer need a model to reinvent.

Measure that claim with matched-model experiments: how much does adding the graph, recipes, capability solver or simulator improve completion and reduce repair cost? Measure context construction and validation overhead too. A subsystem that consumes more time than it saves should be simplified or kept out of the common loop.

Memory is a projection of source-backed decisions and evidence with scope, revision and supersession. External documents, retrieved text, logs and comments cannot change policy or approve their own requests. Local edits and previews use proportionate standing grants; sensitive reads, paid provisioning and consequential external effects have their appropriate boundary.

AI inside the generated application

Model calls, prompts, retrieval, tools, evaluators and agent behaviors become modules with typed input/output, data-access policy, budgets, cancellation, versioned configuration and evaluation fixtures. Put uncertain reasoning inside explicit boundaries and use ordinary actor/protocol/state mechanisms around it. A schema-valid answer is still a model output; business rules and irreversible effects require their own checks.

A small specialized model is a later optimization candidate for graph retrieval/ranking, intent-to-DSL suggestions or diagnostic selection. First gather consented training/evaluation data and demonstrate a persistent bottleneck against retrieval and existing models. Require measurable quality, latency, cost and maintenance gains before training. Do not make a new foundation model a prerequisite for Reaktor or a substitute for Claude/Codex.

See agentic tooling, Koog workbench, Koog agents and browser/local AI.

12. Flows, choreography and the opinionated data/cloud stack

Reaktor should make distributed behavior composable without erasing where it runs, where state is authoritative or what failures are possible. The graph provides a shared description; protocols and adapters give each relationship its execution meaning.

Values, requests, durable work and conversations

Compile these mechanisms onto existing hosts and transports. They share identities and contracts, but a Flow is not durable history and a mobile work scheduler is not an exact distributed deadline.

A protocol facet declares roles, stable steps, payload schemas, branch owner, observable choices, correlation, states, deadlines, retries, authority and terminal outcomes. From a bounded global protocol, generate role-specific state machines, Kotlin/TypeScript bindings, tests and runtime monitors. Reject choices where a participant cannot determine which legal continuation it must follow.

For Requester → Approver → Fulfilment, submission persists a request and deadline; approval controls whether fulfilment may start; timeout changes the domain state; a late external completion is reconciled. Active conversations pin a protocol version. Deploy new and old endpoint support together until drain, or perform an explicit protocol-state migration.

Multiparty session types provide useful projectability, communication-safety and progress ideas. Reaktor must separately model crashes, timeouts, provider behavior and upgrades rather than assume the theory covers arbitrary callbacks or network failures. Honda, Yoshida and Carbone. Use choreography where several roles independently own decisions; a simple request or centrally owned workflow need not acquire an unnecessary global language.

Deep defaults, explicit provider semantics

The reference stack remains deliberately opinionated: Cloudflare is central for edge execution, durable coordination, storage and realtime facilities; GCP supplies heavier compute and Pub/Sub; PostgreSQL is the default primary transactional store. This is how a small team can integrate deeply and ship ambitious applications. Replacement is possible through qualified profiles and migration work, not a promise that every provider is equivalent.

A DO is valuable because it combines keyed coordination and storage, not because all Redis workloads are actors. Prefer actor ownership where the domain benefits; a bulk ephemeral cache or specialist data structure can remain a separate qualified adapter when justified. Cloudflare documents asynchronous interleaving and its storage/lifetime rules, so a single-threaded host still needs the declared actor transition discipline. Durable Object rules.

Keep Supabase convenience separate from database semantics: using PostgreSQL allows a deliberate move to another hosted service or a managed k3s deployment with migration, backups and operational work. GCP can similarly be replaced with another qualified compute provider. Kubernetes improves deployment portability, but storage, identities, networking and regional services still require explicit migration. The plan does not assume that running every database yourself is cheaper or easier.

One authority per datum, explicit projections and completion

The default business path is authenticated command → authoritative transaction plus outbox → durable event/job → idempotent or reconciling consumer → projection/external effect. A DO-owned coordination aggregate or a deliberately Memgraph-owned document can have its own authority; “Postgres primary” does not mean two stores may both silently own the same state.

Keep external IO out of transactions that may retry. PostgreSQL isolation/serialization behavior is a selected adapter profile, not a universal default guarantee. PostgreSQL isolation.

Avoid synchronous triple writes to Postgres, ClickHouse and Memgraph. Projections retain source offsets, reducer versions, lag and rebuild procedures. Authorization-critical decisions use an authority/freshness contract that actually supports them. Object publication stages a blob and commits its reference, with orphan cleanup and reconciliation; strong R2 object consistency is not a transaction across all metadata and objects. R2 consistency.

Pub/Sub ordering depends on subscription/key/region conditions; its optional exactly-once delivery mode does not make arbitrary business effects exactly once. Cloudflare Queues has at-least-once delivery and does not guarantee publication order. A queue bridge must preserve original operation/event identity and prevent loops; order-sensitive actors need an explicit sequencing owner. Pub/Sub ordering, delivery scope, Queues guarantees, Queues ordering.

Offline and external integrations are first-class behaviors

Persist offline intent with original principal/account scope, operation ID, schema and conflict policy. Reconnect revalidates authority and resolves the same logical operation. Logout, account switch, permission revocation, stale reads and a server accepting work just before the connection fails are normal test cases. A generic replication engine should grow from one proven product slice.

Razorpay, Zoho, FCM, Meta/WhatsApp and other business integrations should be replaceable typed modules around real provider contracts. Package verified callbacks/webhooks, scopes, rate limits, deadlines, idempotency/reconciliation, fixtures and compensation with the happy-path API. Treat their exact provider behavior as an adapter support matrix that must be verified when implemented.

A small generated app uses only the stores and services it needs. Recipes provide working defaults; advanced users can inspect the data authority, deployment cut and provider assumptions as the application grows. See Service, DB and sync, server discipline, bus, mesh, work and notifications.

13. Polyglot contracts, FFI and data-oriented execution

Reaktor-FFI should become the common contract and data boundary through which Kotlin, TypeScript, C++ and Python implementations cooperate. Its value is broader than RPC: direct local calls, native buffers, asynchronous streams, remote services and dynamic graph modules can share declared contracts, diagnostics and source mappings.

The design grows the existing Switchboard work. Contract, Implementation, Endpoint, Call, Buffer and Activation are its core FFI concepts; cells/trunks are execution/connection constructs around them. They reference the graph kernel's identities rather than create a competing ontology.

One contract compiler, idiomatic language surfaces

Generate a deterministic descriptor from Kotlin declarations first and accept equivalent descriptors from TypeScript/Python authoring frontends. A method declares stable semantic identity, request/result schemas, call shape, allowed runtime profiles, errors, ordering, cancellation, effects, retry eligibility and budgets. Generate Kotlin suspend/Flow APIs, TypeScript Promise/AsyncIterable, C++ task/stream adapters and Python async/AsyncIterator interfaces.

Separate stable method/field IDs, schema/layout revisions, negotiated session dispatch indices, artifact digests, activation epochs and call IDs. A compact routing index can accelerate repeated calls without becoming a collision-prone permanent identity.

Specify portable values precisely: integer widths/ranges, null versus absence, defaults, enums/unions, byte order, timestamps, unknown fields and errors. Use a lossless representation for 64-bit integers in JavaScript bindings. Arbitrary objects, captured closures, cyclic heaps and nested streams require an explicit supported handle/reference extension; serializable-looking source types are not automatically portable contracts. Unsupported fields must fail generation.

A trusted same-runtime call can use generated direct dispatch while preserving its contract and relevant policy/probes. Serialize where a real boundary requires it. The aim of a “superset of gRPC” is a wider useful execution space, including local synchronous/native calls and data views alongside remote RPC/streams. It should not mean reimplementing every gRPC facility or claiming greater performance before measurement.

Calls and streams with bounded resource semantics

Local synchronous invocation is allowed only for a compatible bounded executor/profile. It must not silently block a UI thread on a network or on a callback that needs the same executor. Remote calls use an explicit asynchronous shape. Executor affinity and reentrancy rules are part of each binding.

Support unary, server-stream, client-stream and bidirectional-stream contracts. Stream frames carry direction, sequence, call identity, bounded payload and lifecycle state. Define start, independent half-close, completion/error, cancellation races, late frames and disconnect. Each local call handle exposes one terminal result; the remote business effect can still have an unknown outcome after disconnection.

Demand is bounded by both item credit and byte/memory capacity. Account for queued and retained buffers; application consumption, buffer release, network receipt and external-effect completion are different events. Reserve capacity for cancellation/credit/terminal control frames and use fair bounded queues. Shared connections still have contention; isolated latency classes may need separate transports.

A cold Flow starts a call on collection unless explicitly shared. A hot state subscription exposes version/current value and conflation; connection state is separate from the application state. Resume requires a validated cursor/checkpoint and compatible producer history. Reconnection alone does not establish durable or exactly-once delivery. Kotlin StateFlow.

gRPC byte flow control and Reaktor item/retention budgets cooperate, but are not identical. Test full queues, slow consumers, stalled readers and cancellation while data capacity is exhausted. gRPC flow control.

The ABI is an ownership and lifecycle contract

Use a versioned C-facing function table with fixed-width fields, opaque endpoint/call/buffer handles and explicit status results. Keep C++ STL types, language exceptions, Kotlin objects and platform-dependent long out of the portable ABI.

A borrowed input lives only for the documented synchronous call/callback. Queuing it requires a retain or copy. An owned immutable buffer is freed through its producer's allocator after the last retained view/lease releases it. Async send success establishes that the runtime acquired its retain/copy, not that execution completed. Failed submission leaves caller ownership intact.

Close stops admissions, drains/cancels by policy, fences scheduled callbacks and signals a completion barrier before callback context or engine destruction. Buffer leases and activation leases are separate: bytes may outlive retired code if their owner survives, but live JSI objects cannot outlive their runtime improperly. Arenas are reclaimed after the final lease, not merely when one batch callback returns.

Translate ordinary exceptions into stable boundary errors. An in-process native memory fault can terminate the process; only an appropriate supervisor/isolation boundary can turn that death into a recoverable endpoint failure. Wire peers send bounded bytes, offsets and negotiated region tokens—not trusted native pointers or allocator instructions. Kotlin/Native scoped allocations and callback references have explicit lifetimes. Kotlin C interop.

FlexBuffers remains central; different data shapes get suitable lanes

FlexBuffers offers direct access without materializing an entire object and supports typed vectors. It does not make every source value or numeric vector identical to a native memory layout. Validate actual widths, bounds and representation before exposing a typed view. FlexBuffers documentation.

For compatible analytical batches, an optional Arrow C Data Interface adapter can preserve arrays across C++/Python boundaries. Its producer/release contract is useful in-process; it is not itself the network transport. Do not impose a full columnar stack on scalar methods. Arrow C Data Interface.

Keep adjacent compute kernels in a suitable data layout, batch FFI crossings and expose conversion/copy boundaries to profiling. An optimizer can propose a fused C++ kernel or bulk Python operation, then validate equivalence and measure it. This makes data-oriented design available across languages while leaving the best execution strategy workload-dependent.

“Zero-copy” is a property of a particular handoff with compatible representation, lifetime, access rights and host support. TLS/network stacks, heap conversion, strides or object materialization may still copy. The current Kotlin hot reader consumes ByteArray; a JNI direct buffer alone does not make it read native memory. Add measured specialized readers/accessors while retaining a safe copy path.

Validate untrusted input before unchecked hot access, and preserve the validity assumptions afterward. A writable JavaScript ArrayBuffer can invalidate a validated native view; TypeScript readonly is not memory protection. Use controlled immutable host access, a sealed copy or a proven exclusive transfer for untrusted modules. Report bytes copied, retained memory and boundary cost instead of advertising universal zero-copy.

Supported transports are named profiles

The official gRPC-Web implementation documents unary/server streaming rather than universal client/bidirectional streaming. Generate a capability diagnostic or choose a supported duplex path. gRPC-Web.

Pin and test the Kotlin-JS, bundler, Hermes and JSI combination. Verify exports, BigInt/Long representation, microtasks, timers and error/source maps using actual generated artifacts. Kotlin-JS export support is not a Hermes compatibility certificate. Kotlin/Wasm and Kotlin-JS/Hermes are separate runtime profiles with different memory/host assumptions. Kotlin-JS interop, Wasm-JS interop.

Flutter binary channels and a C ABI can expose the same semantic contract through different execution paths. Callback resources must remain alive until the receiving isolate runs them; close fences native callbacks before destroying their Dart target. Flutter channels, Dart callback lifecycle.

A practical breakthrough for Python

Do not make access to Python's ecosystem wait for transparent Kotlin/Python heap interop. Publish a normal Python package with generated DTOs, errors, async clients/servers, bounded concurrency, cancellation and graph lifecycle. A developer can attach a scientific/ML worker as an ordinary capability and immediately use it from Kotlin, TypeScript or C++ through the declared process contract.

Then optimize the expensive data boundary: compatible buffers/column batches, batching and an optional native wheel over the same ABI. A Kotlin/JVM implementation still needs a JVM bridge or service; ctypes cannot turn JVM objects into C functions. Qualify OS/architecture/Python versions and real dependencies instead of inferring mobile support from a desktop wheel.

An extension acquires the proper interpreter thread state before touching Python objects and uses event-loop-safe completion. Buffer views keep their exporter/lease alive, validate dtype/strides/byte order/mutability and release exactly once. CPython thread states, Python buffer protocol.

The architectural gain is one module contract across process and optimized local profiles. Applications can gain Python's expressive reach first, then choose tighter integration based on measured latency, memory and deployment needs.

Code push has a host contract and a distribution profile

A marker identifies a module boundary and its transitive dependency closure, not an arbitrary live object. Extract a standalone Kotlin-JS artifact with generated host-capability imports; reject platform-only dependencies and uncontrolled bootstrap state. New native capabilities require a new native host release. Section 9 defines staged activation, state/epoch handling and recovery.

Hermes is not process isolation against native faults. A hard timeout requires a proven interrupt mechanism or host/process isolation; a timer scheduled on the same blocked JS executor cannot stop an infinite loop. Public untrusted modules must receive only the capabilities and execution budget the selected host can enforce.

Keep development reload, owned web/server deployment and public mobile code delivery as distinct profiles. Apple's current review rules restrict downloaded code that changes functionality and place conditions on permitted software categories/native API exposure. Google Play distinguishes prohibited executable self-updates from certain interpreter/VM paths, which must still meet its policies. JavaScript alone does not authorize arbitrary native-capable updates. An ineligible update uses a normal signed app release while retaining fast development iteration. Apple guidelines, Google Play policy. Recheck the actual app/profile and current rules before distribution.

Evidence and sequencing

The first supported FFI boundary needs schema/ABI negotiation, validation, ownership and close/cancellation tests from the start. Prove one useful call profile before expanding streams and hosts. The baseline source has substantive FlexBuffer/compiler/native work, but transport operations, generic argument decoding and stream semantics remain incomplete.

Use a growing golden workload: Kotlin ingests events, C++ computes a batch, eligible Kotlin-JS logic applies a policy, optional Python performs an analysis, and a UI observes versioned state. Add placements/languages one at a time; exercise slow consumers, malformed data, cancellation, provider loss and an update while work is active.

Measure scalar, record, bulk and streaming workloads in release builds: latency distribution, CPU, allocations, copy counts, retained bytes, queue bounds, event-loop stalls, artifact size and update interruption. Compare with handwritten bridges and ordinary protobuf/gRPC on the same hardware. Historical codec results do not establish integrated runtime performance.

The October review supplies measured codec evidence and four open correctness repros; those gates precede adoption. The full wire-to-mutable-memory book informs the separate mutable lane; LiveFlex is a proposed engine, not an implemented feature.

See FlexBuffer implementation, FlexBuffer improvement plan, FFI, FFI design and performance/observability.

14. Studio, IDEs and tools that gain power from the graph

Studio is the Reaktor engine workspace: a powerful development environment for authoring, composing, debugging and operating a whole software system. Its common graph connects product features to source, behavior, modules, runtime islands and cloud resources. Persistent source, Blueprint, preview and diff editors let a developer work with those representations together. Conductor is an optional integrated tool alongside the editors; conversation is one entrance to creation and continued development.

Missions, Graph, Changes, Runs, Evidence and System organize tools and saved perspectives within that persistent workspace. They are not mutually exclusive full-page modes. Project and symbol navigation, Details, run configurations, debugging, the Engine Library and programmable commands support direct work. Map, Trace, Validate and Act remain contextual verbs; auth, data, cloud, AI, testing and UI are domain lenses. The canonical super-IDE atlas defines the latest interaction contract for complete greenfield and brownfield workflows.

Show the representation that answers the question

A nested heterogeneous port graph is the underlying structure, not a requirement to display every object and edge. Use containment and semantic zoom to expand a feature into modules, a module into behavior, or an operation into a causal trace. Show dependency maps, choreography sequences, actor mailboxes, state machines, data lineage, source, timelines and diffs as coordinated projections.

Project defaults provide workspace, current change, principal and preferred target/environment. Each editor can follow or pin its own source/definition revision, activation, time and scope; each run retains the immutable configuration and artifacts of its attempt. A historical trace and current source can remain open together without a global selection relabeling either. An engineer should select a slow screen, find the responsible operation and external dependency, open its profile, make a scoped change, and see the resulting evidence without reconstructing context. Large fleet views need authorized summaries and missing-coverage indicators, not a global object download.

A product author should be able to ask “why is this action disabled?” and get the missing capability, authority or data precondition, the selected fallback and the relevant source. “What would move offline?” should show supported local behavior, new state ownership, conflict policy and the tests it introduces. “What if this service fails?” should open a bounded scenario before it offers a production action.

Integrate tools through semantic contracts

An integration package needs more than a launcher: discovery/schema adapters, query/command definitions, source mappings, effect policy, errors, version compatibility and a conformance fixture. Start with a small depth-first set; a deep profiler or deployment adapter is more valuable than a catalog of unconnected logos.

IntelliJ and VS Code extensions should be thin clients of a local/remote Reaktor project service and the shared schema. Use their existing source language services, debuggers and diff/review mechanisms. Keep Reaktor semantic diagnostics distinct from compiler diagnostics and preserve source mappings through generated wrappers. The first release can offer navigation, diagnostics and task/context handoff before complete visual editing in both IDEs.

A worked north-star scenario

Consider a field-service product with a customer portal, technician mobile app, dispatcher workspace and AI-assisted report drafting. This is a target demonstration, not a claim about a current shipped recipe.

A user creates its journeys and visual identity. The composer selects auth, roles, tasks, files and notifications. A capture feature selects a native camera on a phone, upload in a browser, or an explicit unavailable state; offline submission records intent without pretending approval completed. A job actor owns progress. A choreography defines customer submission, assignment, capture, review and notification, including timeout and duplicate messages. C++ can process image batches locally; Python can analyze data on a permitted worker; TypeScript supplies replaceable report formatting or routing logic. FFI carries declared calls and buffers; capability and authority constraints determine whether local or remote execution is allowed.

The simulator exercises disconnect, reassignment and lost-response cases. A test links the accepted product journey to the actor/protocol implementation. Deployment places the portal and edge endpoints on the reference stack, keeps primary records in Postgres and derives analytics. Later, an approved change to marked report logic is tested against saved scenarios and activated only on a compatible update lane. The developer can trace an unexpected report from UI to actor, native/remote computation, model call, data revision and pushed bundle.

This is how the core ideas should multiply one another: the same declarations improve authoring, runtime adaptation, simulation, debugging and continued change. The domain code remains replaceable, and a simpler app uses only the mechanisms it needs.

Machine Signal remains the workbench token/component source; generated products own their own design identity. December qualifies the supported creation and continued-development slice: source/composition/preview correspondence, readable changes, actionable checks and real deployment outcomes. The engine workspace is the product direction; full atlas parity, every language service and every advanced debugger are sequenced beyond that bounded release. The desktop experience retains its preview status until its own gates pass. See Desktop Master Plan, visual language, graph UI and performance/observability.

15. Build, deploy and operate one reproducible system

The developer loop must work from published packages and a clean clone. Reaktor should carry a project from its first local build to production and later migration without depending on closed-source BestBuds, sibling repositories, maintainer credentials or unpublished generated output.

Build facts become part of the system model

Dependeasy should publish versioned build facts from Gradle/KMP and native configuration: modules, source sets, toolchains, targets, artifacts, generated mappings, task dependencies, tests, budgets and host requirements. npm/Vite, CMake, Xcode, Wrangler and other adapters contribute their authoritative facts. CLI, Studio, CI and agent tools consume the same catalog. Reuse the existing supervised executor and source-definition seals.

The product graph and build graph are related, distinct projections. A feature may span several artifacts; one artifact may contain many nodes. Record that many-to-many mapping so changing a contract identifies clients, tests and deployables without rebuilding the entire fleet.

Published artifacts, compatible warm caches and incremental compilation are product features: they determine whether prompt-to-preview is enjoyable. Cache keys include toolchain, source, configuration and dependency inputs. Generated files should be deterministic; timestamps and local paths belong in provenance rather than semantic content hashes. Verify artifact existence and digest after a successful command.

Compile deployment boundaries with their costs

The planner maps required capabilities and state authorities onto declared runtime islands and existing infrastructure. Begin with explicit placement and explainable checks, then add cost/latency suggestions from observed workloads. An automatic move must preserve protocol, data-residency, authority and failure constraints and go through the normal change path.

Local calls, actor sends, remote requests and durable events have different semantics and costs. A graph edge crossing a deployment cut should reveal the introduced transport, latency, retries, authentication and data movement. This lets Reaktor explain why a composition is expensive and suggest batching, colocating a reducer with its state, or moving a pure compute kernel, with measurements to test the suggestion.

Keep schedulers and infrastructure controllers authoritative for what they operate. Reaktor plans and reconciles through adapters; it does not replace Kubernetes scheduling or invent a second distributed desired-state controller for every resource. Customer-owned environments can later attach through scoped outbound agents with explicit identity, revocation and supported operations.

Release and recovery are graph operations with real state

A release receipt links source/dependency locks, build provenance, artifact and configuration digests, approved effects, executor identity, tests and post-deploy observations. Secrets are resolved at the execution boundary, not embedded in manifests or agent context. Tenant isolation, account switches, credential revocation and sensitive telemetry are tested as normal system behavior.

Rehearse backup restoration and recovery for the actual state authority. A source rollback, code rollback, schema rollback and external-effect compensation are different operations. Plans must name the one they support. Native signing and store submission remain target-specific steps; acceptance by a build pipeline is not a store approval or proof of correct device behavior.

Maintain budgets for first preview, incremental change, startup, memory, binary size, graph/query overhead, p95/p99 application latency, FFI crossings, deployment recovery and total model/build cost. Each budget names workload, hardware/runtime, measurement method and allowed variance. Optimization proposals carry both a profile and a behavioral conformance result. A faster implementation is promotable only if it preserves the contract being relied on.

See build tools, Dependeasy, CLI, DevOps, cloud control and shadow environments.

16. Current system map and intended progression

“Source present” below means meaningful implementation was inspected. It is not a fresh build, deployment or production-readiness verdict. “Partial” means the implementation and target contract differ materially. Dates describe proposed sequencing.

17. What public v1 means

December v1 is a greenfield app builder backed by a usable runtime and development engine. A user must be able to start from an idea, create a functioning full-stack application, deploy it, own its source, and continue changing it. An SDK release, graph inspector or template launcher alone does not satisfy this promise. It includes a stable core package set and explicitly experimental extensions; it does not declare every existing module or platform stable.

The stable launch lane is browser-based creation of responsive multi-user web apps with real auth, persistent data, custom behavior and one asynchronous/integration path. A local developer mode exercises the same project and runtime contracts. Native creation is a required parallel product lane: December must demonstrate generated Android and iOS projects and real device previews for a bounded recipe; broader native support is labeled preview until its own build, capability and distribution gates pass. The target for promoting the native lane is March 2027. Reaktor competes in both web and native creation; maturity is stated separately.

Launch scope is two related web recipe classes—a multi-user workspace/portal and a consumer/community or service-coordination product—plus one bounded native variant over the same backend/modules. AI is an optional capability within these recipes. They are representative coverage, not separate hard-coded generators. Tests must include unseen briefs and follow-up changes that exercise custom behavior beyond the templates.

The proposed stable set is typed composition/contracts and validation; the supported local runtime/lifecycle/actor subset; service/auth/object-storage boundaries used by the reference application; portable manifests/findings/plans/receipts; and the CLI/agent interface needed for the supported change loop. Unstable integration/UI APIs stay versioned as experimental until their own compatibility gates pass.

The public distribution needs an independent repository or package layout for reusable Studio host code now located in BestBuds. Its extraction is a release task: preserve current framework/editor/host ownership boundaries, supply a public reference app, and keep closed product services and data outside the distribution. The user should not need BestBuds credentials to evaluate Reaktor.

Proposed launch support is deliberately tiered:

This matrix is a September decision proposal. Freeze exact runtimes/toolchains, hardware and module versions by 30 September after clean-build evidence. If capacity is lower than assumed, reduce supported rows early. Do not keep a large support promise and weaken its verification.

For the selected December native demonstration, preview means the bounded Android and iOS creation paths actually work with stated limitations; unavailable does not satisfy that commitment. Run the same supported recipe/capability/failure case on both by 30 November. Any reduction to a single native target must be an explicit September scope decision, not a relabeling at launch.

18. The release must prove four complete journeys

Create a real application from an unfamiliar brief

A new user starts in an empty workspace with an unseen product brief. Reaktor creates a distinctive responsive design, working journeys, real authentication and persistent data, plus the requested custom behavior and one asynchronous/integration boundary. The user can refine a screen visually, change behavior conversationally, run the app as two distinct users, publish a preview and export/rebuild the source. Completion is checked against the brief by independent assertions and human UX review.

A second brief exercises the bounded native preview on both Android and iOS, including real navigation, local state, one device capability and its failure path. Native and web clients should share the appropriate service/domain contracts while retaining platform-specific UX. A supplied sample is useful onboarding material but cannot stand in for this creation test.

Grow the application without throwing it away

After initial creation, introduce a change the first prompt did not request: organizations and roles, a state/schema migration, a new approval step or another client. Existing test data must survive; unchanged behavior and visual identity must remain intact. The user sees and resolves a deliberate contract/authorization conflict, while Claude/Codex implements the change through normal source and semantic edits.

Public reference applications make this reproducible and require no private repository or BestBuds credentials. The managed lane removes local setup friction; the local lane remains independently buildable. A native companion extends shared contracts rather than copying a disconnected backend model.

Diagnose a failure and recover without duplicating work

The scenario injects a lost response, duplicate delivery, process restart and denied access. The developer sees the operation identity, state transition, authorization decision, relevant trace and terminal disposition. A recorded counterexample can be replayed locally. Retrying an accepted operation must not duplicate the tested domain effect, and data belonging to another tenant must remain inaccessible.

The model and test boundary must be stated. A simulated external notification cannot establish a real provider's idempotency guarantee. The scenario should include at least one real adapter test in an isolated environment in addition to deterministic simulation.

Deploy a reviewed revision and establish what happened

The developer prepares a plan, sees the target/environment/effects, approves where required, executes the exact plan, and inspects post-deploy evidence. A source or environment change invalidates the previous approval. A failed probe yields an honest partial/failed outcome and a rehearsed recovery action. A stale run never becomes a current health signal.

These four journeys are the minimum coherent product. Atlas screen count, module count, a prebuilt sample and generated lines of code are not substitutes. BestBuds contributes actor/auth/messaging regressions; Manna contributes TypeScript/graph-document/auth-boundary regressions; GymBuddy contributes native lifecycle, storage and capability regressions. Existing-project import is an additional compatibility test, not the only entrance under test.

19. Roadmap from September 2026 to September 2027

The delivery team is two primary developers—Reaktor’s original author and Kedarnath—each working with Codex and Claude. Two humans can own complementary lanes and review each other's work; model parallelism still consumes human integration, design and release attention. The proposed split is one lane for creator/design/client composition and one for runtime/data/runner integration. The developers should choose the actual allocation together; this document does not assign personal responsibilities without that decision.

Use one shared weekly integration target, two substantial implementation lanes and a single release backlog. Reserve roughly one-third of combined capacity for defects, integration, conformance, documentation and support. These are capacity assumptions to adjust from observed throughput. Agent work should end in an integrated change and evidence against the current revision, not a pile of separately completed branches. Review shared contracts before parallel implementations depend on them.

The product critical path remains unfamiliar brief → product/design composition → generated working app → real preview → follow-up change → deploy/export → external user success. Small core improvements belong on that path now: stable contract identity, owned activation scopes, valid wiring, explicit state/effect boundaries and useful findings. Introduce them behind compatibility facades and migrate one generated-app flow plus an internal product flow. A big-bang runtime rewrite, universal compiler or new distributed cluster cannot become a prerequisite for creation.

December scope is a stable browser creator for two related web recipe classes, backed by one selected data/deployment recipe, plus bounded Android and iOS creation previews that both actually build and run. Both native previews exercise the same declared recipe and a capability/failure case on their own targets. Broader native maturity can follow; a browser screenshot or success on only one native platform does not satisfy the promised pair. The local companion shares the browser creator's project protocol instead of requiring a second complete authoring UI.

Priorities define the cut order, not permanent importance. Post-launch dates are forecasts reviewed monthly. The dependency order remains binding: durable actors follow owned local turns and transactional acceptance; choreography projection follows explicit protocol/effect semantics; FFI streams follow call ownership/cancellation; code replacement follows identity, compatibility, authority and recovery; cross-provider placement follows each provider's conformance. Formal methods strengthen these milestones continuously—deterministic checks and executable counterexamples first, deeper models and selected proofs where they earn their cost.

Each platform milestone must unlock an observable application capability or improve a difficult follow-up change. Under pressure, cut advanced operator panes, universal visual programming, extra providers/backends, marketplace/collaboration and exotic app domains before weakening the complete creation journey, both promised bounded native previews, data correctness or authority gates. If a gate still fails, publish an honest narrower preview and state the missed commitment; do not substitute an SDK/inspector release for the agreed builder.

20. Non-negotiable December release gates

Every gate is a proposed acceptance requirement. None is reported as passed by this document.

The date is a forcing function for scope. It does not override a correctness or security gate. If a non-negotiable gate still fails, publish an explicitly labeled preview and report that v1 missed its gate; do not rename an unsafe beta as stable. The working plan is to avoid that outcome by cutting optional scope in September and October.

21. Measuring whether Reaktor is winning

Use two primary outcomes: time to a genuinely usable first application, and verified change throughput as it grows. The second measures accepted changes that satisfy an independent behavior contract per unit of total developer time and cost. Record design/interaction quality, correctness, regressions, human intervention, time, compute/model cost and recovery together. A fast attractive scaffold with broken behavior fails the first outcome; a speed improvement that increases escaped defects fails the second.

Publish a benchmark specification and reference briefs. Retain at least six unseen evaluation briefs across the declared app classes, with withheld growth requirements, until each scored run completes; then publish results and rotate the holdouts. Run repeated trials. Test visual quality, real persistence/auth, schema evolution, tenant isolation, duplicate delivery, native capability fallback, deployment recovery and clean export. Existing-project integration is a separate track. Independent assertions and human product review should judge outcomes; do not let the system grade only the tests it generated.

Run two comparison tracks. The product track compares Reaktor with Emergent, Rork and other selected builders from the same empty-project brief, time/cost ceiling and target outcomes, using each product's available model and idiomatic stack. Stratify by supported target: a web-only builder's lack of a native lane is a coverage difference, not a failed native-quality trial. Record model differences instead of claiming a controlled same-model experiment when a builder does not expose that choice. The substrate track pins the same Claude/Codex model, configuration and budget with and without Reaktor, giving the baseline competent libraries and specialist tools. This separates whether the product wins from which engine mechanisms contribute. Include cold setup, paid compute/model use, failures and repair/maintenance cost.

Initial targets to calibrate during September, rather than advertise as results:

• First interactive design preview within 10 minutes; first functioning authenticated/persistent journey within 30 minutes; supported deployment within 60 minutes when provider prerequisites are satisfied. Publish cold starts, setup prerequisites and brief complexity separately.
• Median clean exported-project first-run time under 30 minutes on the supported setup; no BestBuds/private repository credential needed.
• At least four of five November external trial developers finish the basic journey without unrecorded help.
• No accepted stale plan or cross-tenant access in the release's specified negative-test matrix.
• At least 90% completion of the supported golden journey trials by the December candidate, with every failure classified; critical correctness assertions still require 100% pass.
• By September 2027, demonstrate either a material reduction in total time/cost or higher correct-task completion against a strong same-agent baseline, with no reliability regression. Set the numerical improvement target after collecting the baseline.

Also track repeat use, upgrade success, module reuse across products, time to diagnose a failure, escaped regressions, build latency, runtime overhead and context size per resolved task. Stars, generated code volume and polished screenshots are secondary signals.

Measure the core mechanisms, not only the final demo

Run ablations that remove recipe reuse, graph context, capability planning, incremental checks or simulation while keeping the task and agent budget comparable. Record which mechanism increases correctly completed behavior, reduces integration work or prevents a relevant failure. Include its runtime, build and cognitive overhead.

Maintain a primitive-coverage matrix across the reference domains: how many mechanisms and custom glue changes are needed to add a new product behavior? Track reusable failure cases, unchanged module reuse, cross-language conversions, memory retained at boundaries and time to make a compatible follow-up change. The desired result is increasing application complexity and verified change throughput without proportional growth in bespoke code, outages or operator effort. Publish uncertainty and cases where a simpler stack wins.

22. Adoption, distribution and the ten-year position

Reaktor becomes a default through repeated creation success, continued usefulness and ecosystem independence. The public creator should make a new idea real. A package should also solve a valuable task in an existing project. Examples should show complete systems; the module format should let another developer add a capability without joining the core team. The release process should let all of them keep upgrading.

The recommended public foundation is an inspectable open core with portable schemas, a usable local runtime/tooling path, ordinary package distribution and documented extension contracts. Audit the existing license and all bundled dependencies before choosing release terms; this plan does not silently change them. Hosted collaboration, managed environments, enterprise policy and support can become commercial products without making basic local correctness checks or export dependent on a paid service.

Claude/Codex integration should feel native, but the application model should not depend on a single model vendor's conversation format. Reaktor should preserve projects, receipts and invariants when the user changes model or tool. This is how model improvements compound instead of forcing framework migrations.

The durable advantage is the combination of lawful composition, real adapters, an executable failure corpus, useful agent context and a trusted compatibility ecosystem. Any individual pane or wrapper is easy to imitate. Maintaining those pieces together across years of application changes is the work that can justify long-term adoption.

The first external audience includes founders/designers creating a new product and developers building greenfield apps who want both AI speed and a maintainable foundation. Offer a clear Create path and a professional code-first path into the same artifacts. Existing-project adopters are valuable too, but must not dominate launch messaging. Publish creation examples, a small contract reference, growth/failure-driven tutorials and clear supported/experimental labels. Invite contributors to a recipe, adapter or invariant with a conformance kit, not a sprawling internal backlog.

Beyond year one: expand the engine's reach

The ten-year direction is a sequence of earned capabilities, not a fixed calendar of universal promises. First make real app creation and continued growth dependable. Then expand the reusable module/adapter ecosystem and compositional verification. Use those foundations for deeper offline collaboration, scientific/data workflows, native media, independently operated services and device fleets. Eventually, domain-specific execution profiles can bring bounded real-time control or stronger assurance requirements into the same authoring and evidence model.

The invariant through that expansion is a compact common core with specialist implementations. Every new domain should contribute reusable contracts, capabilities, protocols or tools back to the engine. Every compiler/runtime optimization should retain the program's meaningful identities and the evidence needed to change it. This is how Reaktor can grow beyond its original analogies without becoming a collection of disconnected products.

23. Decisions that keep the vision coherent

These decisions refine the core design and constrain implementation choices. Detailed subsystem documents retain their useful specifications; where they prescribe incompatible semantics, the decisions below identify what this plan replaces. Each implementation ADR must name its owner, compatibility/migration effect, failure behavior and executable acceptance case.

The next two weeks: 7–20 September 2026

By 30 September, freeze the initial schema/identity decisions, source ownership, public package/support matrix, licensing/distribution proposal, authority/effect boundary and generated workflow acceptance cases. Later refinements should carry an explicit migration, rather than creating another parallel semantic system.

24. Reading map and maintenance contract

This page owns the north star, system-level decisions, support promises, sequencing and outcome measures. It specifies the cross-system contracts and refinements needed to make the core ideas work together, and links to detailed subsystem designs and historical audits. The implementation schedule is the selected two-developer program; separate research notes are inputs, not additional promised parallel roadmaps. When an implementation changes status, update the system map and attach revision/target evidence. When a decision changes, record what it supersedes. Keep historical audits available with dates.

Older roadmaps retain their detailed work and historical rationale. This page supplies the new September 2026–September 2027 ordering; it does not turn an old proposed capability into an implemented one. The complete target is a development engine whose power grows with its modules, models and agents, while its guarantees remain understandable to the people relying on the software.