Impact, design obligations and qualification

Design synthesis, 7 October 2026. This chapter incorporates the supplied Astra report. Its models and acceptance tests describe intended architecture; they do not certify current implementation. The report inventoried 140 public routes and compared substantive sections of 51 documents. Repository source and current qualification receipts determine what ships.

Architecture thesis and invariants · Nodes, ports and hyperedge vocabulary · Composition and execution semantics · Compiler, source publication and consistency · Shadow, evidence and region releases · Authoring and industry precedents · Cross-runtime systems and worked scenarios · Impact, design obligations and qualification

15. Ecosystem impact and complexity frontier

Reaktor can potentially solve families of boundary problems: cross-runtime feature composition; native-resource access; durable command execution; offline state and synchronization contracts; live sessions; safe deployment; environment reproduction; cross-tool context drift; agent mutation safety; inspection and authorization; adaptive model placement; and multi-surface behavior reuse. A single feature may benefit from several, which is where the composition can be more valuable than isolated wrappers.

The nearest precedents should sharpen—not weaken—the differentiation. Ptolemy supplies heterogeneous execution semantics; MLIR supplies extensible compiler structure; databases supply atomic change; Kubernetes and Erlang supply realization and upgrades; FoundationDB supplies disciplined simulation. MPS’s experimental Projectional Agent Toolkit now gives agents structured model-editing and validation facilities. “Agents can edit a typed graph” alone is therefore not a defensible uniqueness claim. [Ptolemy II: hierarchy, ports and models of computation] [MLIR — Dialect conversion] [JetBrains MPS — Projectional Agent Toolkit (2026.1, experimental)] [Kubernetes — Controllers] [Erlang/OTP — Release handling] [FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)]

The stronger hypothesis is that Reaktor lowers the total cost of accepted, cross-layer changes across mobile, browser, server, data, native and operational boundaries. That should be tested against the best ordinary stack, not a deliberately weak baseline.

Do not equate this with increasing computational power beyond a general programming language. The target is the feasible frontier at a fixed team, time, reliability, cost and performance budget. Domain understanding, algorithm design, product judgment and external failures remain essential difficulty. A broad framework can also impose modeling, dependency, adoption and lock-in costs.

An Amdahl-style fixed-work sensitivity model illustrates the fixed-work case. If 60% of work improves fourfold with no overhead, the overall factor is about 1.82, not four. That is an illustration, not a forecast. The model also misses a second benefit: teams may attempt larger or riskier designs because the cost of safe experimentation falls. [Amdahl — Validity of the single processor approach (1967)] [Reaktor plan and roadmap] [FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)]

16. Design obligations and open findings

1. Capability tier versus constrained offer

Classification: Documentation conflict

Keep tier as presentation. Eligibility must satisfy schema, protocol, placement, privacy, lifetime and authority before preference ranking. Re-selection needs stability and session migration rules.

Acceptance test: A higher-quality remote model is rejected when private inputs cannot leave the device; fallback is observed and testable.

Sources: Capability selection, Reaktor plan and roadmap

2. Evidence kinds versus an ordinal ladder

Classification: Design correction

Replace minimum EvidenceLevel with a claim-indexed evidence requirement. Bounds, assumptions, checker trust and exact artifacts are part of the claim.

Acceptance test: A successful production trace cannot discharge a universal no-unauthorized-write claim; a proof of a model cannot discharge a measured latency SLO.

Sources: Formal methods and evidence, Shadow verification and capsules

3. Binary kernel examples versus n-ary relationships

Classification: Documentation reconciliation

Choose typed incidence records as the structural substrate. Binary invocation, ownership and hyperedge protocols are qualified relation schemas.

Acceptance test: A session has exactly one authority and many participants; this must not conflict with a unary consumer’s exclusive-binding rule.

Sources: Graph substrate redesign, Data graph, Formal methods and evidence

4. Protocol and completion semantics

Classification: Omission from design

Make admitted, persisted, processed, canceled and reconciled outcomes explicit per protocol. Require versioned behavioral compatibility, not only matching record layouts.

Acceptance test: Inject reply loss after commit. The caller reconciles the same command receipt instead of duplicating the logical effect.

Sources: Service contracts, Graph protocol, Data workflows, Surface contracts and interaction

5. Lifecycle, ownership and handover

Classification: Omission from design

Model host lifetime, component ownership, task scope and resource leases separately. Persist required work before acknowledging host-local completion.

Acceptance test: Destroy a browser/Worker host without cleanup callbacks; prove durable intent survives or declare a weaker profile.

Sources: Component lifecycle, Actor execution model, Durable work, FFI / Switchboard

6. Source-backed transaction publication

Classification: New boundary to make explicit

Source edits, graph revisions and built artifacts may have different authorities. Stage and pin a candidate; compare source revision; record recoverable publication phases.

Acceptance test: Crash after materializing source but before promoting the graph. Recovery must not publish a mixed source/artifact revision.

Sources: Source ownership, Visual language, DevOps integration

7. Incremental analysis is more than visitors

Classification: Sharper mechanism

Use a dependency-tracked query/analysis service for positive and negative facts. Run generic visitors as one client, not the only execution model.

Acceptance test: Insert a new provider that invalidates a previous absence result; its query, binding and verification evidence all become stale.

Sources: Module execution plan, Graph visitors, McSherry et al. — Differential Dataflow, Mokhov, Mitchell & Peyton Jones — Build Systems à la Carte

8. Time scales and specialized execution

Classification: Omission from design

Separate definition revisions, activation roots, reactive values, durable workflow events and native frame/tick state. Bind observations back by identity.

Acceptance test: Animate at the host frame rate without committing architecture revisions; replace a UI region without discarding an active IME draft.

Sources: Surface contracts and interaction, Dynamic UI and verification, Surface performance and assets, Operational graph evidence

9. Coordination and collaboration boundaries

Classification: Sharper invariant policy

Use serialized authority commits first. Permit coordination-free merges only for operations proven safe under the required merge/invariant model.

Acceptance test: Two private branches add different providers to one exclusive port. Individually valid does not mean jointly valid.

Sources: Stable foundations, Data transactions, PostgreSQL — Transaction isolation, Bailis et al. — Coordination Avoidance in Database Systems

10. Evidence capture and privacy

Classification: Omission from design

Keep trace sampling separate from replay completeness. Exactly one substitution owner per effect; mark loss and unavailable joins. Retention and suppression apply to every derived workspace.

Acceptance test: Deleted source data does not reappear after Shadow base reconstruction; duplicated collectors do not replay one effect twice.

Sources: Operational graph evidence, Capture fabric, Capture and replay, Shadow workspaces, Shadow verification and capsules

11. Meta-schema and qualification evolution

Classification: New explicit obligation

Version module semantics, contracts and checker implementations. Unknown required semantics block activation; evidence binds the interpreter/checker versions.

Acceptance test: An upgraded dialect changes cancellation semantics without changing payloads. Old compatibility and evidence must not silently survive.

Sources: Formal methods and evidence, Module execution plan, MLIR — Dialect conversion, Surface contracts and interaction

12. Storage engine ambition

Classification: Implementation simplification

Define graph storage semantics independently of physical layout. Start with a qualified existing transactional authority plus immutable graph indexes; custom WAL/GC only when measured needs justify it.

Acceptance test: Crash-recovery and snapshot-lifetime tests pass before any performance claim; old snapshots retain their own resolution directory.

Sources: Stable foundations, Mutable memory and publication, SQLite — Isolation

13. Product intent and reusable feature boundaries

Classification: Omission from design

Connect changes to acceptance contracts and user journeys, not only types. Reusable regions carry assumptions, effects, migrations and operational tests.

Acceptance test: The feature compiles and deploys, but loses a user draft or breaks accessibility; its acceptance gate still rejects it.

Sources: Reaktor plan and roadmap, Surface contracts and interaction, Dynamic UI and verification

14. Design truth versus implementation truth

Classification: Documentation hygiene

Every normative claim gets status, owner, source revision, implementation pointers and qualifying tests. Separate historical criticism from active contract.

Acceptance test: No generated compliance view may show a design-only streaming guarantee as implemented merely because a document describes it.

Sources: FFI / Switchboard, Formal methods and evidence, Workbench layers, Shadow workspaces

15. Graph integration without dependency cycles

Classification: Sharper architectural rule

Low-level reaktor-core and graph-free policy/storage primitives need not import the graph. Higher-level module contributions expose their identities, capabilities and effects to the graph.

Acceptance test: The foundational libraries remain usable headlessly while every admitted operational boundary is registered and inspectable.

Sources: Core dependency boundary, Module execution plan, Build control-plane responsibilities

16. External harness authority is not graph authority

Classification: New trust-boundary finding

Model provider configuration, raw harness arguments, subprocess/network access and inherited tools as effective execution authority. Isolate untrusted runs or mark the governance claim incomplete.

Acceptance test: A denied graph mutation must not become authorized merely by asking an inherited harness tool to perform the same external action.

Sources: Conductor harness boundaries, Workbench layers, Formal methods and evidence, Shadow verification and capsules

17. Implementation and validation sequence

Start with descriptor-driven palette/source mapping and one qualified behavior profile. Add release manifests and activation images before promising arbitrary node hot-swap. Then prove a single end-to-end update through Service, FFI, Work, Data and Shadow, reusing existing graph/storage authorities rather than creating another IR or ownership universe.

Acceptance tests: preserve the semantic digest after layout-only edits; reject a missing native descriptor; detect a stale-evidence candidate; widen an update when a shared state schema changes; preserve old calls under the old image; survive a lost activation reply; reject stale callbacks after resource disposal; refuse an unauthorized capability escalation; and recover from a partially rolled-out fleet.

Benchmark node-by-node interpreter overhead against compiled region execution, physical bytes transmitted versus semantic change size, time to compile/invalidate, retained-generation memory, and hot-path FFI copies. More granular updates can reduce change scope, but they can also prevent inlining and increase dispatch cost; make the tradeoff selectable per region.

Product thesis: Stately-like precision for behavior, Unreal-like engine composition, Cursor-like expert editing, FlutterFlow-like product iteration and Expo-like runtime-aware delivery—all expressed through Reaktor’s governed distributed-system model. The value must be demonstrated by a difficult full-stack change that remains typed, authorized, testable and recoverable.

First: settle the common contract vocabulary—identity, typed incidences, region/source ownership, protocols, effect/authority separation, lifetime and claim-indexed evidence. Preserve compatibility façades while this becomes the source of truth.

Second: qualify one complete change loop on existing storage and runtime primitives. A stateful service/Work path should admit a command, commit an exact receipt, survive acknowledgement loss, run under current tenant authority, and remain inspectable across restart.

Third: add graph-aware incremental compilation and evidence invalidation. Begin conservatively; validate optimization against the reference semantics and failure corpus. Avoid implementing custom storage, distributed scheduling and a new compiler backend simultaneously.

Fourth: prove the cross-runtime composition on a difficult feature, such as a multiplayer or live-media workflow with native buffers, browser/mobile interaction, a model provider, durable results and mixed-version rollout. Inject disconnects, stale policies, failed migrations, duplicate delivery and host disappearance.

Finally: run external-team ablations: ordinary tooling; Reaktor libraries without global graph automation; graph-aware plans and typed agent operations; and the full Shadow/governance loop. Hold feature requirements and model/harness versions constant. Measure accepted-change lead time, regression escape rate, recovery, unauthorized-action prevention, onboarding, memory/call overhead and ability to leave the platform.

The essential deliverable is not a larger picture. It is a small compositional core whose promises remain true while the surrounding system changes.

18. Documentation coverage

140 current navigation routes retrieved/inventoried; 51 targeted substantive section comparisons. The remaining routes were not fully substantively audited. Counts include the canonical FFI alias. Additional legacy and private-access failures are in the ledger. This is not an immutable snapshot of the site or a repository audit.

Complexity frontier and ecosystem impact

Measure the whole accepted change, including modeling, tests, adapters and operational recovery.

Law / model / proof obligation: S = 1 / [(1−f) + f/s + h], a hypothetical fixed-work sensitivity model.

Reaktor design decision

Reaktor could reduce cross-tool translation, duplicated configuration, agent context assembly and incident reproduction. More importantly, verified experimentation may make previously too-risky refactors affordable.

What this does not establish

Essential algorithms, product discovery and cross-system failure remain difficult. A new semantic platform can add lock-in, training, bottlenecks and maintenance cost. No market-size or productivity multiplier is measured here.

Falsifiable acceptance test. Use external-team ablations and count escaped defects, unsafe action attempts, onboarding, recovery, runtime overhead and accepted-change lead time—not generated lines of code.

Theory, precedent and Reaktor context: Amdahl — Validity of the single processor approach (1967) Reaktor plan and roadmap FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)

Design obligations and open findings

Sixteen findings: existing concepts omitted from our synthesis, documentation inconsistencies, and proposed corrections. These are not a repository security or correctness audit.

Documentation conflict

01. Capability tier versus constrained offer

Keep tier as presentation. Eligibility must satisfy schema, protocol, placement, privacy, lifetime and authority before preference ranking. Re-selection needs stability and session migration rules.

Acceptance: A higher-quality remote model is rejected when private inputs cannot leave the device; fallback is observed and testable.

Capability selection Reaktor plan and roadmap

Design correction

02. Evidence kinds versus an ordinal ladder

Replace minimum EvidenceLevel with a claim-indexed evidence requirement. Bounds, assumptions, checker trust and exact artifacts are part of the claim.

Acceptance: A successful production trace cannot discharge a universal no-unauthorized-write claim; a proof of a model cannot discharge a measured latency SLO.

Formal methods and evidence Shadow verification and capsules

Documentation reconciliation

03. Binary kernel examples versus n-ary relationships

Choose typed incidence records as the structural substrate. Binary invocation, ownership and hyperedge protocols are qualified relation schemas.

Acceptance: A session has exactly one authority and many participants; this must not conflict with a unary consumer’s exclusive-binding rule.

Graph substrate redesign Data graph Formal methods and evidence

Design gap

04. Protocol and completion semantics

Make admitted, persisted, processed, canceled and reconciled outcomes explicit per protocol. Require versioned behavioral compatibility, not only matching record layouts.

Acceptance: Inject reply loss after commit. The caller reconciles the same command receipt instead of duplicating the logical effect.

Service contracts Graph protocol Data workflows Surface contracts and interaction

Design gap

05. Lifecycle, ownership and handover

Model host lifetime, component ownership, task scope and resource leases separately. Persist required work before acknowledging host-local completion.

Acceptance: Destroy a browser/Worker host without cleanup callbacks; prove durable intent survives or declare a weaker profile.

Component lifecycle Actor execution model Durable work FFI / Switchboard

Required boundary

06. Source-backed transaction publication

Source edits, graph revisions and built artifacts may have different authorities. Stage and pin a candidate; compare source revision; record recoverable publication phases.

Acceptance: Crash after materializing source but before promoting the graph. Recovery must not publish a mixed source/artifact revision.

Source ownership Visual language DevOps integration

Sharper mechanism

07. Incremental analysis is more than visitors

Use a dependency-tracked query/analysis service for positive and negative facts. Run generic visitors as one client, not the only execution model.

Acceptance: Insert a new provider that invalidates a previous absence result; its query, binding and verification evidence all become stale.

Module execution plan Graph visitors McSherry et al. — Differential Dataflow Mokhov, Mitchell & Peyton Jones — Build Systems à la Carte

Design gap

08. Time scales and specialized execution

Separate definition revisions, activation roots, reactive values, durable workflow events and native frame/tick state. Bind observations back by identity.

Acceptance: Animate at the host frame rate without committing architecture revisions; replace a UI region without discarding an active IME draft.

Surface contracts and interaction Dynamic UI and verification Surface performance and assets Operational graph evidence

Sharper invariant policy

09. Coordination and collaboration boundaries

Use serialized authority commits first. Permit coordination-free merges only for operations proven safe under the required merge/invariant model.

Acceptance: Two private branches add different providers to one exclusive port. Individually valid does not mean jointly valid.

Stable foundations Data transactions PostgreSQL — Transaction isolation Bailis et al. — Coordination Avoidance in Database Systems

Design gap

10. Evidence capture and privacy

Keep trace sampling separate from replay completeness. Exactly one substitution owner per effect; mark loss and unavailable joins. Retention and suppression apply to every derived workspace.

Acceptance: Deleted source data does not reappear after Shadow base reconstruction; duplicated collectors do not replay one effect twice.

Operational graph evidence Capture fabric Capture and replay Shadow workspaces Shadow verification and capsules

Required obligation

11. Meta-schema and qualification evolution

Version module semantics, contracts and checker implementations. Unknown required semantics block activation; evidence binds the interpreter/checker versions.

Acceptance: An upgraded dialect changes cancellation semantics without changing payloads. Old compatibility and evidence must not silently survive.

Formal methods and evidence Module execution plan MLIR — Dialect conversion Surface contracts and interaction

Implementation simplification

12. Storage engine ambition

Define graph storage semantics independently of physical layout. Start with a qualified existing transactional authority plus immutable graph indexes; custom WAL/GC only when measured needs justify it.

Acceptance: Crash-recovery and snapshot-lifetime tests pass before any performance claim; old snapshots retain their own resolution directory.

Stable foundations Mutable memory and publication SQLite — Isolation

Design gap

13. Product intent and reusable feature boundaries

Connect changes to acceptance contracts and user journeys, not only types. Reusable regions carry assumptions, effects, migrations and operational tests.

Acceptance: The feature compiles and deploys, but loses a user draft or breaks accessibility; its acceptance gate still rejects it.

Reaktor plan and roadmap Surface contracts and interaction Dynamic UI and verification

Documentation hygiene

14. Design truth versus implementation truth

Every normative claim gets status, owner, source revision, implementation pointers and qualifying tests. Separate historical criticism from active contract.

Acceptance: No generated compliance view may show a design-only streaming guarantee as implemented merely because a document describes it.

FFI / Switchboard Formal methods and evidence Workbench layers Shadow workspaces

Sharper architectural rule

15. Graph integration without dependency cycles

Low-level reaktor-core and graph-free policy/storage primitives need not import the graph. Higher-level module contributions expose their identities, capabilities and effects to the graph.

Acceptance: The foundational libraries remain usable headlessly while every admitted operational boundary is registered and inspectable.

Core dependency boundary Module execution plan Build control-plane responsibilities

Trust boundary

16. External harness authority is not graph authority

Model provider configuration, raw harness arguments, subprocess/network access and inherited tools as effective execution authority. Isolate untrusted runs or mark the governance claim incomplete.

Acceptance: A denied graph mutation must not become authorized merely by asking an inherited harness tool to perform the same external action.

Conductor harness boundaries Workbench layers Formal methods and evidence Shadow verification and capsules

Documentation coverage

140 navigation routes retrieved; 51 received targeted substantive section comparisons. The remainder were inventoried, not fully substantively audited. The count includes archives and the FFI design alias; it is not a count of unique implementations or 140 fully read documents. This is not an atomic snapshot of a changing site and is not a source-code audit.

Additional legacy routes and a private authentication boundary are listed below. No completeness claim is made about unlinked, private or unavailable material.

140 routes

Additional and inaccessible material

• codex-reaktor-notifications-design/ — additional legacy page retrieved. legacy design; not counted among 140 current navigation routes.
• multiplatform-analysis/ — search-index material only; direct retrieval failed. not fully reviewed.
• react-compose/ — search-index material only; direct retrieval failed. not fully reviewed.
• architecture-analysis/ — search-index material only; direct retrieval failed. not fully reviewed.
• https://reaktor.build/private/astra-analysis — authentication redirect. not accessible; not reviewed.

Route discovery used the current site navigation plus indexed legacy material. Proposed behavior, source presence, passing tests, deployed behavior and current operational qualification remain distinct statuses throughout this report.

Primary sources

A mechanism-by-mechanism reading map, not a novelty claim. Papers and official documentation establish their own guarantees, not those of an unqualified Reaktor implementation.

1. The Living GraphReaktor document · living
2. Graph substrate redesignReaktor document · substrate
3. Reaktor plan and roadmapReaktor document · roadmap
4. Formal methods and evidenceReaktor document · formal
5. Stable foundationsReaktor document · stable
6. Capability selectionReaktor document · cap
7. Module execution planReaktor document · module
8. Graph visitorsReaktor document · visitors
9. Component lifecycleReaktor document · life
10. Actor execution modelReaktor document · actors
11. Distributed actorsReaktor document · dactors
12. Graph protocolReaktor document · protocol
13. Source ownershipReaktor document · sources
14. Service contractsReaktor document · service
15. Data graphReaktor document · data
16. Data transactionsReaktor document · txn
17. Durable workReaktor document · work
18. Data workflowsReaktor document · workflows
19. MultitenancyReaktor document · tenant
20. Surface contracts and interactionReaktor document · surface
21. Dynamic UI and verificationReaktor document · dynamic
22. Surface performance and assetsReaktor document · surfaceperf
23. Surface renderersReaktor document · renderer
24. FFI / SwitchboardReaktor document · ffi
25. Mutable memory and publicationReaktor document · liveflex
26. Shadow foundationsReaktor document · shadow
27. Shadow workspacesReaktor document · workspace
28. Shadow verification and capsulesReaktor document · verify
29. Capture and replayReaktor document · replay
30. Capture fabricReaktor document · capture
31. Operational graph evidenceReaktor document · ops
32. DevOps integrationReaktor document · devops
33. Workbench layersReaktor document · layers
34. Visual languageReaktor document · visual
35. HangarReaktor document · hangar
36. Authentication moduleReaktor document · auth
37. Ptolemy II: hierarchy, ports and models of computationPrimary precedent · ptolemy
38. Lee & Parks — Dataflow Process Networks (1995)Primary precedent · processnets
39. Compositionality of dataflow modelsPrimary precedent · compositiondataflow
40. Fong — Decorated Cospans (2015)Primary precedent · cospan
41. Fong & Spivak — Seven Sketches in CompositionalityPrimary precedent · sketches
42. Patch Graph Rewriting: comparison with DPO rewritingPrimary precedent · rewrite
43. Foster et al. — Combinators for Bidirectional Tree TransformationsPrimary precedent · lenses
44. Honda, Yoshida & Carbone — Multiparty Asynchronous Session TypesPrimary precedent · mpst
45. A Mechanised Theory of Multiparty Asynchronous Session Types (ECOOP 2025)Primary precedent · mpstproof
46. van der Aalst et al. — Soundness of workflow netsPrimary precedent · petri
47. Cozzo et al. — Structure of Triadic Relations in Multiplex NetworksPrimary precedent · multilayer
48. MIT OpenCourseWare — Queueing theory and Little’s lawPrimary precedent · queues
49. MLIR — Dialect conversionPrimary precedent · mlir
50. MLIR — InterfacesPrimary precedent · interfaces
51. Koka — Types and effect handlersPrimary precedent · effects
52. WebAssembly Component Model — WITPrimary precedent · wit
53. Apache Arrow — C data interfacePrimary precedent · arrow
54. SQLite — IsolationPrimary precedent · sqlite
55. PostgreSQL — Transaction isolationPrimary precedent · postgres
56. Bailis et al. — Coordination Avoidance in Database SystemsPrimary precedent · iconfluence
57. FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)Primary precedent · fdb
58. Lamport — Distributed clocks, snapshots and temporal specificationsPrimary precedent · lamport
59. Lamport — A high-level view of TLA+Primary precedent · tla
60. Kubernetes — ControllersPrimary precedent · k8s
61. Temporal — Workflow executionPrimary precedent · temporal
62. Erlang/OTP — Release handlingPrimary precedent · otp
63. Mokhov, Mitchell & Peyton Jones — Build Systems à la CartePrimary precedent · build
64. McSherry et al. — Differential DataflowPrimary precedent · differential
65. Unison — Code as content-addressed definitionsPrimary precedent · unison
66. JetBrains MPS — Projectional Agent Toolkit (2026.1, experimental)Primary precedent · mps
67. Functional Mock-up Interface — Model exchange and co-simulationPrimary precedent · fmi
68. Unreal Engine — Introduction to BlueprintsPrimary precedent · blueprint
69. Jetpack Compose — Architecture and statePrimary precedent · compose
70. Amdahl — Validity of the single processor approach (1967)Primary precedent · amdahl
71. Core dependency boundaryReaktor document · core
72. Conductor harness boundariesReaktor document · conductor
73. Build control-plane responsibilitiesReaktor document · buildtools
74. Dependeasy build factsReaktor document · dependeasy
75. Bus versus live MeshReaktor document · bus
76. Live session topologyReaktor document · mesh
77. Tidemark data layerReaktor document · db