References, notation, exercises and source lineage
Technical preprint, 16 September 2026 — web reading edition. This preserves the supplied paper’s content and its historical evidence boundary. Proposed interfaces, conditional propositions and constructed studies are not released APIs or deployment proof. Aligned equations, tables and listings retain their source layout. Source figure pages retain the original vector artwork. The accompanying finite model and coverage-map source package were not supplied; their reported results have not been independently reproduced here.
Current guides: reaktor-data-implementation · architecture-atlas-qualification.
The engine and feature composition · Graph model, protocols and computation · Platforms, identity and polyglot execution · Data authority, contracts and federation · Build, compilation and resource budgets · LiveUpdate, coordinator and human-agent authoring · Assurance and adoption studies · Precedents, evaluation and implementation sequence · References, notation, exercises and source lineage
References
[1] Epic Games. Introduction to Blueprints. Official documentation. Documentation. Accessed September 2026. [2] Epic Games. Coding in Unreal Engine: Blueprint vs. C++. Official documentation. Documentation. Accessed September 2026. [3] Reaktor Project. Framework Overview. Project documentation source, 2026. Pinned source; public route. [4] Reaktor Project. Visual Language — Blueprints. Project documentation source, 2026. Pinned source; public route. [5] Reaktor Project. Reaktor Build Tools. Project documentation source, 2026. Pinned source; public route. [6] Reaktor Project. Reaktor DevOps. Project documentation source, 2026. Pinned source; public route. [7] Reaktor Project. Graph Kernel Analysis. Project documentation source, 2026. Pinned source; public route. [8] Reaktor Project. Unified System Graph. Project documentation source, 2026. Pinned source; public route. [9] Reaktor contributors. Reaktor source code. Graph kernel, graph runtime, and service modules. Source baseline 42ccdc96e772a10ce9a6580274f73f3fa02e0acc, 2026. Repository snapshot. [10] BestBuds Ventures. BestBuds application source: shared messaging API, service clients, test implementations, and application graph. Source baseline dcc5df82e7cd6e8e6b7cd6ebd7f2bc37ef9ea43d, 2026. Private project source. Repository snapshot. [11] Epic Games. Technical Guide for Blueprints Visual Scripting. Official documentation. Documentation. Accessed September 2026. [12] Epic Games. Blueprint Debugger. Official documentation. Documentation. Accessed September 2026. [13] Epic Games. Asset management in Unreal Engine. Primary assets, dependency tracking, loading, and packaging. Official documentation. Accessed September 2026. [14] Epic Games. Game Features and Modular Gameplay. Official documentation. Documentation. Accessed September 2026. [15] Epic Games. Gameplay Ability System. Abilities, effects, attributes and lifecycle. Official documentation. Accessed September 2026. [16] Reaktor Project. Auth Architecture and Redesign. Project documentation source, 2026. Pinned source; public route. [17] Reaktor Project. Reaktor Notifications. Project documentation source, 2026. Pinned source; public route. [18] Reaktor Project. Shadow Dev Environment. Project documentation source, 2026. Pinned source; public route. [19] Reaktor Project. Dependeasy. Project documentation source, 2026. Pinned source; public route. [20] Reaktor Project. Reaktor CLI. Project documentation source, 2026. Pinned source; public route. [21] Reaktor Project. Reaktor Core. Project documentation source, 2026. Pinned source; public route. [22] Reaktor Project. Reaktor Service. Project documentation source, 2026. Pinned source; public route. [23] Cloudflare. Service bindings. Official documentation. Documentation. Accessed September 2026. [24] Cloudflare. Service bindings: Remote-procedure calls. Official documentation. Documentation. Accessed September 2026.
[25] Reaktor Project. Actor Model. Project documentation source, 2026. Pinned source; public route. [26] Reaktor Project. Reaktor FFI — Switchboard. Project documentation source, 2026. Pinned source; public route. [27] Reaktor Project. Engine and Website Implementation Report. Project documentation source, 2026. Pinned source; public route. [28] Reaktor Project. Graph Visitors. Project documentation source, 2026. Pinned source; public route. [29] Gilles Kahn. The semantics of a simple language for parallel programming. In Information Processing 74: Proceedings of the IFIP Congress, pp. 471–475, North-Holland, 1974. The constructive treatment in Reference [30] provides a machine-oriented account of the denotational model. [30] Christine Paulin-Mohring. A constructive denotational semantics for Kahn networks in Coq. Chapter 17 in From Semantics to Computer Science: Essays in Honour of Gilles Kahn. Cambridge University Press, 2010. Publisher chapter. [31] Reaktor Project. Hierarchical Graph UI. Project documentation source, 2026. Pinned source; public route. [32] Simon Brown. The C4 model for visualising software architecture. Official documentation. Documentation. Accessed September 2026. [33] Reaktor Project. Flow Analysis. Project documentation source, 2026. Pinned source; public route. [34] Mikko Kivelä, Alexandre Arenas, Marc Barthelemy, James P. Gleeson, Yamir Moreno, and Mason A. Porter. Multilayer networks. Journal of Complex Networks, 2(3):203–271, 2014. arXiv:1309.7233. [35] Reaktor Project. Reaktor architecture documents: Graph Kernel Analysis; Unified System Graph; Graph Sources; Data Layer; Service Layer; Control Plane; Graph Visitors. Project design corpus, 2026. Documenta-tion collection. [36] Eric Lehman, F. Thomson Leighton, and Albert R. Meyer. Mathematics for Computer Science. MIT course text, 2015. Course text and readings. [37] Kohei Honda, Vasco T. Vasconcelos, and Makoto Kubo. Language primitives and type discipline for structured communication-based programming. In European Symposium on Programming, LNCS 1381, pp. 122–138, 1998. doi:10.1007/BFb0053567. Subsequent session-type developments refine the definitions and proof conditions; no session-type theorem is assumed for arbitrary Reaktor protocols. [38] Joseph M. Hellerstein and Peter Alvaro. Keeping CALM: When distributed consistency is easy. Preprint, 2019. arXiv:1901.01930. [39] Peter Bailis, Alan Fekete, Michael J. Franklin, Ali Ghodsi, Joseph M. Hellerstein, and Ion Stoica. Coordination avoidance in database systems. Extended version, 2014. arXiv:1402.2237. [40] Nancy A. Lynch. Distributed Algorithms. Morgan Kaufmann, 1996. ISBN 9781558603486. Companion MIT course readings. [41] Christel Baier and Joost-Pieter Katoen. Principles of Model Checking. MIT Press, 2008. ISBN 9780262026499. Publisher page. [42] Brendan Fong and David I. Spivak. Seven Sketches in Compositionality: An Invitation to Applied Category Theory. Open manuscript, 2018. arXiv:1803.05316. Published as An Invitation to Applied Category Theory, Cambridge University Press, 2019. [43] Lucas Dixon and Aleks Kissinger. Open graphs and monoidal theories. Technical report, 2010. arXiv:1011.4114. [44] Nneka Chinelo Ene, Maribel Fernández, and Bruno Pinaud. Attributed hierarchical port graphs and applica-tions. Electronic Proceedings in Theoretical Computer Science, 265:2–19, 2018. doi:10.4204/EPTCS.265.2. arXiv:1802.06492. [45] Philip Chodrow and Andrew Mellor. Annotated hypergraphs: Models and applications. Preprint, 2019. arXiv:1911.01331. [46] Giorgio Gallo, Giustino Longo, Stefano Pallottino, and Sang Nguyen. Directed hypergraphs and applications. Discrete Applied Mathematics, 42(2–3):177–201, 1993. doi:10.1016/0166-218X(93)90045-P. [47] GraphBLAS Forum. GraphBLAS: graph algorithms in the language of linear algebra. Mathematical foundations and sparse-algebra interfaces. Project documentation. Accessed September 2026.
[48] J. A. Bondy and U. S. R. Murty. Graph Theory. Graduate Texts in Mathematics 244, Springer, 2008. doi:10.1007/978-1-84628-970-5. [49] Fan R. K. Chung. Spectral Graph Theory. CBMS Regional Conference Series in Mathematics 92. American Mathematical Society, 1997. Author’s supporting material. [50] Hartmut Ehrig, Karsten Ehrig, Ulrike Prange, and Gabriele Taentzer. Fundamentals of Algebraic Graph Transformation. Springer, 2006. doi:10.1007/3-540-31188-2. [51] Chris Lattner, Mehdi Amini, Uday Bondhugula et al. MLIR: A compiler infrastructure for the end of Moore’s law. Preprint, 2020. arXiv:2002.11054. [52] Edward A. Lee and David G. Messerschmitt. Synchronous data flow. Proceedings of the IEEE, 75(9):1235– 1245, 1987. Author publication page. doi:10.1109/PROC.1987.13876. [53] Edward A. Lee and David G. Messerschmitt. Static scheduling of synchronous data flow programs for digital signal processing. IEEE Transactions on Computers, C-36(1):24–35, 1987. Author publication page. [54] Tadao Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541–580, 1989. doi:10.1109/5.24143. [55] Alan M. Turing. On computable numbers, with an application to the Entscheidungsproblem. Proceedings of the London Mathematical Society, s2-42(1):230–265, 1937; received 1936. doi:10.1112/plms/s2-42.1.230. [56] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558–565, 1978. doi:10.1145/359545.359563. [57] James C. Corbett et al. Spanner: Google’s globally-distributed database. In USENIX Symposium on Operating Systems Design and Implementation, 2012. Author publication page. [58] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374–382, 1985. doi:10.1145/3149.214121. [59] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM, 35(2):288–323, 1988. doi:10.1145/42282.42283. [60] Seth Gilbert and Nancy Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2):51–59, 2002. doi:10.1145/564585.564601. [61] Maurice P. Herlihy and Jeannette M. Wing. Linearizability: A correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems, 12(3):463–492, 1990. doi:10.1145/78969.78972. [62] Jerome H. Saltzer, David P. Reed, and David D. Clark. End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4):277–288, 1984. Author-hosted paper. [63] Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference, pp. 305–319, 2014. Conference paper. [64] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. In Stabilization, Safety, and Security of Distributed Systems, LNCS 6976, pp. 386–400, 2011. doi:10.1007/978- 3-642-24550-3_29. [65] Reaktor Project. Reaktor Capability. Project documentation source, 2026. Pinned source; public route. [66] Reaktor Project. Component Lifecycle. Project documentation source, 2026. Pinned source; public route. [67] Reaktor Project. BestBuds Architecture Refactor. Project documentation source, 2026. Pinned source; public route. [68] Reaktor Project. Graph Refinement Plan. Project documentation source, 2026. Pinned source; public route. [69] Service Weaver project. Service Weaver: component-based application development and deployment. Project documentation. Accessed September 2026. [70] Hydro project. Location-Oriented Programming and Locations and Networking. Programming-model documentation; location reference. Accessed September 2026. [71] Reaktor Project. Reaktor Data Layer. Project documentation source, 2026. Pinned source; public route. [72] Reaktor Project. BestBuds Schema Hardening. Project documentation source, 2026. Pinned source; public route.
[73] OpenLineage project. Object Model. OpenLineage specification. Official specification. Accessed September 2026. [74] Paul Groth and Luc Moreau, editors. PROV-Overview: An Overview of the PROV Family of Documents. W3C Working Group Note, 30 April 2013. W3C specification. [75] Bazel contributors. Hermeticity. Build-system documentation. Official documentation. Accessed September 2026. [76] Eelco Dolstra. The Purely Functional Software Deployment Model. Ph.D. thesis, Utrecht University, 2006. Project publication announcement. [77] Reaktor Project. Multitenancy. Project documentation source, 2026. Pinned source; public route. [78] Reaktor Project. Reaktor Secrets. Project documentation source, 2026. Pinned source; public route. [79] Reaktor Project. Security Plan — MLS end-to-end encryption. Project documentation source, 2026. Pinned source; public route. [80] Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, and Katriel Cohn- Gordon. The Messaging Layer Security (MLS) Protocol. RFC 9420, IETF, July 2023. Official specification. doi:10.17487/RFC9420. [81] Reaktor Project. Reaktor Work. Project documentation source, 2026. Pinned source; public route. [82] Android Developers. Persistent background work. Official documentation. Documentation. Accessed Septem-ber 2026. [83] Apple. Choosing background strategies for your app. Official documentation. Documentation. Accessed September 2026. [84] Reaktor Project. Reaktor Bus. Project documentation source, 2026. Pinned source; public route. [85] Reaktor Project. Reaktor Mesh. Project documentation source, 2026. Pinned source; public route. [86] Firebase. Setting the lifespan of a message. Official documentation. Documentation. Accessed September 2026. [87] Reaktor Project. Deep Link Integration. Project documentation source, 2026. Pinned source; public route. [88] Reaktor design materials. LiveUpdate and cross-runtime execution. Unpublished architecture memorandum, 2026. Execution domains, artifact requirements, Hermes regions, FFI dispatch, state policy, and update generations. [89] Reaktor Project. Reaktor FlexBuffer Performance Guide. Project documentation source, 2026. Pinned source; public route. [90] Reaktor Project. Reaktor UI and Tactile. Project documentation source, 2026. Pinned source; public route. [91] Reaktor Project. React × Compose Blueprint. Project documentation source, 2026. Pinned source; public route. [92] Reaktor Project. React × Compose Interop Roadmap. Project documentation source, 2026. Pinned source; public route. [93] React Native contributors. Bundled Hermes. React Native architecture documentation. Official documentation. Accessed September 2026. [94] Dagger Project. CI integrations: Jenkins. Official documentation. Documentation. Accessed September 2026. [95] Pulumi. Automation API. Official documentation. Documentation. Accessed September 2026. [96] Reaktor Project. Reaktor Cloud Control Plane. Project documentation source, 2026. Pinned source; public route. [97] Reaktor Project. Analytics and Telemetry. Project documentation source, 2026. Pinned source; public route. [98] Reaktor Project. Performance and Observability. Project documentation source, 2026. Pinned source; public route. [99] Reaktor Project. Graph Sources. Project documentation source, 2026. Pinned source; public route.
[100] Epic Games. Overview of Mass Entity. Unreal Engine documentation. Official documentation. Accessed September 2026. [101] Epic Games. Render Dependency Graph. Unreal Engine documentation. Official documentation. Accessed September 2026. [102] Richard Fabian. Data-Oriented Design: Software Engineering for Limited Resources and Short Schedules. 2018. Author’s site and online text. [103] Samuel Williams, Andrew Waterman, and David Patterson. Roofline: An insightful visual performance model for multicore architectures. Communications of the ACM, 52(4):65–76, 2009. doi:10.1145/1498765.1498785. Earlier author technical report. [104] Gene M. Amdahl. Validity of the single processor approach to achieving large scale computing capabilities. In AFIPS Spring Joint Computer Conference, pp. 483–485, 1967. doi:10.1145/1465482.1465560. [105] John D. C. Little. A proof for the queuing formula: 𝐿 = 𝜆𝑊. Operations Research, 9(3):383–387, 1961. doi:10.1287/opre.9.3.383. [106] Linux kernel contributors. What is RCU?—Read, Copy, Update. Kernel documentation. Official documenta-tion. Accessed September 2026. [107] Bureau International des Poids et Mesures. The International System of Units (SI). Ninth edition, 2019, with online supporting material. Definitions and measurement units. [108] Expo. Runtime versions and updates. EAS Update documentation. Official documentation. Accessed September 2026. [109] Expo. Error recovery. EAS Update documentation. Official documentation. Accessed September 2026. [110] The Update Framework. Roles and metadata. Official documentation. Accessed September 2026. [111] Apple. App Review Guidelines, including Section 2.5.2. Official policy. Accessed September 2026. Distribu-tion rules require review for the applicable release channel. [112] Google. Device and network abuse. Google Play Developer Program Policy. Official policy. Accessed September 2026. [113] Reaktor Project. Agentic Tooling / Control Plane. Project documentation source, 2026. Pinned source; public route. [114] Reaktor Project. Koog Workbench. Project documentation source, 2026. Pinned source; public route. [115] Reaktor Project. Gemini DevOps Agent. Project documentation source, 2026. Pinned source; public route. [116] Reaktor Project. Koog for the BestBuds Bot. Project documentation source, 2026. Pinned source; public route. [117] Reaktor Project. Browser-Local AI. Project documentation source, 2026. Pinned source; public route. [118] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. Preprint, 2024. arXiv:2405.15793. [119] Anthropic. Effective harnesses for long-running agents. Engineering report, 2025. Report. [120] OpenAI. Harness engineering: leveraging Codex in an agent-first world. Engineering report, 2026. Report. [121] Parker Whitfill, Cheryl Wu, Joel Becker, and Nate Rush. Many SWE-bench passing PRs would not be merged into main. METR research note, 10 March 2026. Study report. The experiment concerns its specified agents, repositories, and review procedure, not a general bound on future systems. [122] Daniel Jackson. Software Abstractions: Logic, Language, and Analysis. Revised edition, MIT Press; paperback edition, 2016. ISBN 9780262528900. Publisher page. [123] Nikolaj Bjørner, Leonardo de Moura, Lev Nachmanson, and Christoph Wintersteiger. Programming Z3. Online technical tutorial. Author-maintained text. Accessed September 2026. [124] Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley, 2002. Author’s book and supporting material.
[125] Xudong Sun, Wenjie Ma, Jiawei Tyler Gu, Zicheng Ma, Tej Chajed, Jon Howell, Andrea Lattuada, Oded Padon, Lalith Suresh, Adriana Szekeres, and Tianyin Xu. Anvil: Verifying liveness of cluster management controllers. In 18th USENIX Symposium on Operating Systems Design and Implementation, pp. 649–666, 2024. Conference publication. [126] Jeremy Avigad, Leonardo de Moura, Soonho Kong, and Sebastian Ullrich. Theorem Proving in Lean 4. Online textbook. Official text. Accessed September 2026. [127] NASA. Systems Engineering Handbook, Section 2: Fundamentals of systems engineering. NASA/SP-2016- 6105 Rev. 2, online edition. Handbook section. Accessed September 2026. [128] NASA. Systems Engineering Handbook, Section 5: Product realization. NASA/SP-2016-6105 Rev. 2, online edition. Handbook section. Accessed September 2026. [129] Chris Hawblitzel, Jon Howell, Manos Kapritsos, Jay R. Lorch, Bryan Parno, Justine Stephenson, Srinath Setty, and Brian Zill. IronFleet: Proving practical distributed systems correct. In ACM Symposium on Operating Systems Principles, 2015. Author publication page. [130] Gerwin Klein et al. seL4: Formal verification of an OS kernel. In ACM Symposium on Operating Systems Principles, 2009. doi:10.1145/1629575.1629596. Project explanation of proof scope and assumptions. [131] Chris Newcombe, Tim Rath, Fan Zhang, Bogdan Munteanu, Marc Brooker, and Michael Deardeuff. How Amazon Web Services uses formal methods. Communications of the ACM, 58(4):66–73, 2015. Author publication page. doi:10.1145/2699417. [132] Open Robotics and ROS 2 contributors. About quality of service settings. ROS 2 Humble documentation. QoS concepts and compatibility. Accessed September 2026. [133] Geoffrey Biggs and Tully Foote. Managed nodes. ROS 2 design document, 2015, revised 2021. Design specification. [134] Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. HyTech: A model checker for hybrid systems. International Journal on Software Tools for Technology Transfer, 1:110–122, 1997. Project and publications. [135] Thomas A. Henzinger, Peter W. Kopke, Anuj Puri, and Pravin Varaiya. What’s decidable about hybrid automata? Technical Report UCB/ERL M98/22, University of California, Berkeley, 1998. Technical report. [136] Aaron D. Ames, Samuel Coogan, Magnus Egerstedt, Gennaro Notomista, Koushil Sreenath, and Paulo Tabuada. Control barrier functions: Theory and applications. In European Control Conference, pp. 3420–3431, 2019. arXiv:1903.11199. doi:10.23919/ECC.2019.8796030. [137] Karl J. Åström and Richard M. Murray. Feedback Systems: An Introduction for Scientists and Engineers. Princeton University Press, 2008. Author-hosted first edition. [138] Reaktor Project. Reaktor Arena. Project documentation source, 2026. Pinned source; public route. [139] Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: You own your data, in spite of the cloud. In ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, pp. 154–178, 2019. Author-hosted essay and paper. doi:10.1145/3359591.3359737. [140] Don Batory. Feature models, grammars, and propositional formulas. In Software Product Lines, LNCS 3714, pp. 7–20, Springer, 2005. doi:10.1007/11554844_3. [141] Reaktor Project. Nexergy Energy on Reaktor — Codex. Project documentation source, 2026. Pinned source; public route. [142] Reaktor Project. Nexergy Commerce Substrate — Claude. Project documentation source, 2026. Pinned source; public route. [143] Martín Abadi et al. TensorFlow: A system for large-scale machine learning. In USENIX Symposium on Operating Systems Design and Implementation, pp. 265–283, 2016. Conference paper. [144] Reaktor Project. CompanyOS Migration. Project documentation source, 2026. Pinned source; public route. [145] Epic Games. Replication Graph. Official documentation. Accessed September 2026. [146] Xavier Leroy and CompCert contributors. The CompCert C compiler: a trustworthy compiler. Manual, overview and semantic-preservation guarantees. Official manual. Accessed September 2026.
[147] Harshit Saokar et al. ServiceRouter: Hyperscale and minimal cost service mesh at Meta. In USENIX Symposium on Operating Systems Design and Implementation, pp. 969–985, 2023. Conference paper. [148] Ruoming Pang et al. Zanzibar: Google’s consistent, global authorization system. In USENIX Annual Technical Conference, 2019. Author publication page. [149] Dapr Project. Building blocks. Official documentation. Documentation. Accessed September 2026. [150] Backstage contributors. Software catalog and Well-known relations between catalog entities. Catalog documentation; Relation semantics. Accessed September 2026. [151] Jingyu Zhou et al. FoundationDB: A distributed unbundled transactional key value store. In ACM SIGMOD International Conference on Management of Data, pp. 2653–2666, 2021. doi:10.1145/3448016.3457559. Project publication summary. [152] Iulian Neamtiu, Michael Hicks, Gareth Stoyle, and Manuel Oriol. Practical dynamic software updating for C. In ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 72–83, 2006. Author publication page. [153] Christopher M. Hayden, Edward K. Smith, Michail Denchev, Michael Hicks, and Jeffrey S. Foster. Kitsune: Efficient, general-purpose dynamic software updating for C. In ACM International Conference on Object Ori-ented Programming Systems Languages and Applications, pp. 249–264, 2012. doi:10.1145/2384616.2384635. [154] Robert Nystrom. Crafting Interpreters. Genever Benning, 2021. Author’s online edition. [155] Keith D. Cooper and Linda Torczon. Engineering a Compiler. Second edition, Morgan Kaufmann, 2011. Publisher page. [156] Jason Gregory. Game Engine Architecture. Third edition, CRC Press, 2018. Author’s companion site. [157] Victor Dibia. Designing Multi-Agent Systems: Principles, Patterns, and Implementation. Online book. Author’s site. Accessed September 2026.
Original page layout, starting at page 98
A. Notation and representation interfaces
Table 13 summarizes the principal objects. The notation separates identities, semantic descriptions, and implementation handles throughout the architecture.
Symbol or object Meaning
𝑁, 𝑃, 𝐸, 𝐽 Nodes, owned ports, edges, and incidence occurrences.
𝑜, 𝑎, 𝑏, 𝑟 Ownership, incidence-to-edge, incidence-to-port, and role maps.
𝜏, 𝐹 Type assignments and schema-checked attributes.
𝑀 = (𝐻, 𝐵, 𝛽) An open module and its exposed owned endpoints.
𝜂(𝑥) The interaction semantics of edge 𝑥.
⟦𝐻⟧ A behavioral transition-system interpretation.
𝜌 Logical-to-physical realization mapping.
𝑅 A release mapping compatible graph, artifact, and boundary revisions.
𝑈, 𝑈 ′ Old and replacement update regions.
Δ A revision-relative graph patch.
𝛼 The abstraction from physical storage to the semantic graph.
𝜑, 𝐴 A property and its assumptions.
Table 13: Core notation. Observation times and runtime generations are not interchangeable with semantic revision identifiers.
The following record sketch illustrates a compact semantic API. Each identifier is an opaque, scoped identity; implementations can intern it to a dense index. Referenced descriptor types are versioned records defined by the corresponding subsystem.
data class NodeSpec(
val id: NodeId, val kind: NodeKindId,
val scope: ScopeId, val implementation: ImplementationRef?,
)
data class PortSpec(
val id: PortId, val owner: NodeId,
val name: SymbolId, val endpointType: EndpointTypeId,
val bindingCardinality: Cardinality,
)
data class EdgeSpec(
val id: EdgeId, val edgeType: EdgeTypeId,
val semantics: InteractionProfileId,
)
data class IncidenceSpec(
val id: IncidenceId, val edge: EdgeId, val port: PortId,
val role: RoleId, val membership: MembershipPolicyId?,
)
data class UpdateManifest(
val release: ReleaseId, val expectedBase: ReleaseId,
val region: UpdateRegionId, val patch: GraphPatch,
val artifacts: List<ArtifactRef>,
val hostRequirements: HostRequirements,
val activation: ActivationPlan,
val stateTransition: StateTransitionPlan,
val recovery: RecoveryPlan,
)
Original page layout, starting at page 105
B. Update failure obligations
A recovery test suite should cover each transition that can leave durable state different from the currently published execution view. Table 14 gives the minimum categories; individual adapters can require additional cuts.
Table 14: Failure cases and required outcomes for a supported update profile.
Failure point Risk Required behavior
Interrupted download Partial or inconsistent artifacts Do not load until authenticated content and
dependency checks succeed.
Candidate initialization Unintended production effects Deny unapproved effects; discard isolated
staged resources on failure.
Safe point unavailable Forced interruption of a Defer, use an explicitly approved
session or writer termination policy, or reject activation.
Migration interrupted Partially converted durable Resume or recover from a recorded
state migration phase; never infer schema from
artifact selection alone.
Ownership transferred Old execution view with a Enforced fencing rejects old writes;
before publication stale writer recovery selects a compatible generation or
a restricted state.
Failure point Risk Required behavior
Publication completed Uncertain updater outcome Read the durable release/journal state and
before resolve idempotently.
acknowledgement
Delayed callback after Dispatch into a reused slot Validate registry and generation; reject or
swap deliver to a still-protected old generation.
Candidate fails after Unsafe code rollback Use only a state-compatible recovery
writes artifact or an authorized forward repair.
Old generation never Unbounded retained memory Apply a declared lifetime/termination
drains policy; retain safety even if retirement is
delayed.
Stale signed metadata Unauthorized downgrade or Enforce freshness, version, trust-root, and
mixed release coherent snapshot rules.
Original page layout, starting at page 106
C. Terminology and reading conventions
The terms below distinguish concepts that are often conflated in architecture diagrams. They are definitions used by this specification, not claims that every community uses the same vocabulary.
Term Meaning in this specification
Engine Reusable implementation mechanisms and their authoring, execution, lifecycle,
and tooling contracts; not one mandatory global runtime.
Blueprint A supported visual/textual behavior language over a reified graph, distinct from
a dependency diagram or UI render tree.
Feature package A versioned open module with the implementations and companions needed for
its declared support profile.
Node A semantic component or entity with an identity. A node need not be a heap
object, process, or independently deployed service.
Port An interface endpoint owned by exactly one node. Its type includes a signature,
protocol shape, and endpoint role.
Edge / hyperedge A structural connection with two or multiple incidence occurrences,
respectively. Behavior is supplied by its protocol and coordination profile.
Incidence One attachment occurrence linking an edge, port, and role. Distinct incidences
preserve repeated roles and subscription identities.
Protocol A specification of permitted observable communication, including sequencing,
completion, cancellation, and applicable errors.
Realization An implementation of a logical component or connection using artifacts,
runtimes, resources, and adapters.
Reference Access to a local interface or capability. It is not automatically serializable or
remotely realizable.
Relation A typed semantic connection between entities, such as declaration, protection,
lineage, ownership, or observation.
Facet Typed local metadata attached to an entity; not a substitute for a topology with
independent relationships.
Aspect A related vocabulary and topology, such as authorization or data lineage,
anchored to system identities.
Projection A query-derived view with stated filtering and completeness. Different
projections can legitimately have different paths.
Term Meaning in this specification
Open module A subgraph with explicit exposed boundary endpoints and internal ownership.
Composition connects boundaries without giving a port two owners.
Authority The source or protocol permitted to establish a class of facts. It is not
synonymous with a physical server or organizational contact.
Desired state Declared configuration or intended deployment. It does not imply current
physical existence.
Observation Evidence obtained from an execution or provider, with provenance, time, and
coverage limits.
Runtime instance A particular executing realization of a logical component. Several instances can
realize one logical node.
Invocation / attempt An invocation is the logical unit of requested work; an attempt is one execution
or delivery effort associated with it.
Graph revision A coherent version of structural declarations and compatible references within
an authority boundary.
Execution view The compatible mapping of bindings and versions used by a unit of work. Its
lifetime may outlast the current graph revision.
Update region A supported open subgraph whose replacement is mediated through declared
interfaces and lifecycle rules.
Generation A runtime incarnation of a replaceable boundary. It is distinct from an artifact
hash, schema version, and UI sequence.
Safe point A condition at which a specified update transition is permitted. It may concern
calls, state, resources, or physical machinery.
Fencing epoch A value checked by the effect authority to reject obsolete owners. A lease or
local generation counter alone is not equivalent enforcement.
Recovery An authorized transition from a failure state to an acceptable state. It may
require forward repair rather than code rollback.
Invariant A predicate required to hold in every reachable state of the specified model.
Safety / liveness Safety excludes forbidden finite behavior; liveness requires eventual progress
under stated assumptions.
Refinement A relation establishing that a more concrete model satisfies the relevant abstract
behavior and obligations.
Assurance evidence A scoped result: proof, bounded check, test, observation, or assumption. These
categories are not interchangeable.
Feasible system space Systems realizable under selected mechanisms, policies, environments, and
budgets. It is not generally a vector space.
Escape hatch An explicitly identified path outside a supported analyzable dialect. It requires
conservative summaries or a reduced assurance claim.
Original page layout, starting at page 107
D. Reproducibility of the finite reference model
The accompanying source archive contains models/generation_model.py and models/results.j
son. The script uses the Python standard library and performs breadth-first exploration of a deliberately
finite generation-lifetime model. Running the following command from the archive root regenerates the
result file:
python3 models/generation_model.py --output models/results.json
The result records the configured reader and generation bounds, transition counts, safety outcomes, and the unsafe protocol’s counterexample. The model represents acquisition, release, monotonic publication,
and reclamation. Generations are prepared initially; no implementation code is dynamically loaded by the experiment. The finite result is useful because a common implementation error has a short witness, and the safe model’s reachable-state counts also admit the independent combinatorial cross-check in Section 31. The artifact does not test Reaktor’s current Kotlin, C++, or Hermes implementation. It does not model memory ordering, crashes, state migration, counter overflow, or arbitrary future generations. Extending those assumptions changes the model and requires a new result. The LaTeX source is self-contained and includes the bibliography and vector diagrams. Compilation requires a conventional TeX distribution with the packages declared in the preamble. The source archive records the commands used to generate the PDF and model output. Citation URLs identify literature and source baselines; private project references are not required to understand or run the finite example.
Original page layout, starting at page 108
E. Study guide and implementation exercises
The curriculum follows the architecture’s dependencies rather than treating its bibliography as a reading queue. Each stage should produce a small implementation, model, counterexample, or measurement. The learning nodes and prerequisite relations can be entered into Manna, with artifact completion as evidence of mastery. The sequence is suitable for a systems programmer developing mathematical fluency; experienced readers can enter at the relevant branch.
E.1 Stage 1: relations, logic, and proof
Begin with the relations, induction, state-machine, and invariant material in Mathematics for Computer Science [36]. Use Bondy and Murty [48] for directed graphs, connectivity, cuts, and related algorithms. Read Jackson’s Software Abstractions [122] alongside these topics, so that a mathematical definition immediately becomes a model that can produce counterexamples. Artifact. Define nodes, owned ports, incidence occurrences, roles, and open boundaries in a small relational model. Include parallel edges and two distinct incidences involving the same endpoint. Check invalid ownership, missing references, and ambiguous bindings. Implement a graph-to-incidence encoding and test round-trip identity preservation on generated examples. Completion criterion. Explain the difference between assuming an invariant and checking that a transition preserves it. Produce at least one counterexample and revise either the model or the intended rule. A correct diagram without a defined transition is not completion.
E.2 Stage 2: network representations and linear algebra
Study incidence and adjacency matrices, sparse representations, connected components, and eigenvectors. Fong and Spivak’s signal-flow material [42], Chung’s spectral treatment [49], and GraphBLAS’s sparse-algebra vocabulary [47] connect algebra to graph operations. Read the multilayer-network and hypergraph references selectively for representation choices [34, 45, 46]. Artifact. Encode a publication and an AND-join with the same endpoint sets. Compute their incidence-derived structural adjacency, then demonstrate why identical reachability does not imply identical enabling behavior. Partition a measured toy workload using a declared cost function and compare the result with an exact enumeration of its small candidate space. Completion criterion. Explain which information each projection loses. Use a vector for numerical objectives without claiming that arbitrary application architectures form a vector space.
E.3 Stage 3: execution semantics and computability
Use Nystrom [154] for a concrete interpreter and Cooper and Torczon [155] for intermediate representations and lowering. Read Kahn-network semantics and its constructive treatment [29, 30], synchronous dataflow [52, 53], Petri nets [54], and Turing’s computability argument [55] as distinct models rather than interchangeable graph formalisms. Artifact. Build a small executable behavior dialect with conditions, iteration, state, and explicit effects. Implement a statically rated streaming fragment, derive its balance equations, and show a bounded-buffer deadlock that the unbounded idealization excludes. Sketch a Turing-machine simulation using the dialect’s explicit storage assumptions. Completion criterion. State where termination is decidable in the implemented subset, where it is only checked within bounds, and why unrestricted completeness limits automatic verification.
E.4 Stage 4: distributed algorithms and consistency
Lynch’s Distributed Algorithms [40] supplies I/O automata, failure models, composition, and simulations. Read Lamport’s clock paper [56], linearizability [61], FLP, partial synchrony, and CAP with their exact hypotheses [58, 59, 60]. Study Raft [63] as a concrete protocol, not as a synonym for every replicated system. Use invariant confluence and CRDTs [39, 64] to reason about which independent updates can merge safely. Artifact. Implement one shared service interface with local and remote realizations. Introduce a lost response after a committed update. Specify scoped deduplication, a durable outbox, and a checkpoint-based read-your-writes path. Build an actor ownership model in which a stale holder is rejected at the protected resource. Completion criterion. Distinguish request failure from unknown outcome, arrival order from causal order, and a failure detector’s suspicion from proof that an old owner has stopped.
E.5 Stage 5: specification and model checking
Read Lamport’s Specifying Systems [124], then use Baier and Katoen [41] for transition systems, safety, liveness, fairness, abstraction, and temporal logic. Jackson remains useful for the relational side. The Z3 tutorial [123] provides a separate path for configuration and placement constraints. Artifact. Reproduce the supplied generation-lifetime model, then extend it with an interruption during preparation or with a stateful handoff. Build small TLA+ models for patch publication and queue delivery. Remove a fairness assumption and identify the resulting non-progress behavior. Encode a placement problem with satisfiable and inconsistent configurations, preserving unknown results as unknown. Completion criterion. Write the model scope and assumptions next to every result. Translate a counterexample into a test that exercises an actual boundary implementation.
E.6 Stage 6: hardware and data-oriented execution
Fabian [102] supplies an access-pattern perspective; Gregory [156] connects memory, execution, tools, and lifecycle in an engine. Use Roofline, Amdahl’s law, Little’s law, and RCU [103, 104, 105, 106] to predict costs before measuring them. Unreal’s RDG and MassEntity show concrete separation of declarations, processing, and storage [101, 100]. Artifact. Compare object-oriented, compact binary/n-ary, and incidence-based graph stores behind the same semantic API. Measure traversal, patches, allocations, direct-call overhead, and peak memory during coexistence. Add safe publication, reader pinning, and retirement. Check stable identity after compaction.
Completion criterion. Explain at least one mismatch between a simple performance model and observed behavior. Do not declare one layout universally superior; identify the workloads for which it wins and loses.
E.7 Stage 7: composition, rewriting, and extensions
Study Fong and Spivak’s database, signal-flow, circuit, and behavioral examples [42], then hierarchical port graphs and open graphs [44, 43]. Ehrig and colleagues [50] develop typed rewriting, preserved interfaces, and application conditions. Batory’s feature-model connection to propositional logic [140] is useful for product families and configuration constraints. Artifact. Specify ownership-preserving module composition, implement a structural patch checker, and document its deletion conditions. Package one new protocol or runtime realization with its typing rules, lifecycle, effects, tests, inspection metadata, and assurance obligations. Demonstrate a previously infeasible scenario under a fixed environment and identify the assumptions needed for conservative extension. Completion criterion. Explain which theorem applies to the chosen encoding and why a structural composition law does not automatically prove behavioral compatibility.
E.8 Stage 8: dynamic updating and recovery
Ginseng and Kitsune [152, 153] expose safe points and state transformation. Hermes and Expo documentation [93, 108, 109] connect update artifacts to installed runtimes. TUF [110] supplies the update trust model. Artifact. Implement one replaceable boundary with signed artifacts, explicit host requirements, unchanged host-owned state, next-entry activation, and independent recovery. Interrupt every journal transition. Only after that profile works, add draining and generation coexistence. Include a callback into an obsolete generation, a missing native capability, and a migration for which code rollback is unsafe. Completion criterion. Separate artifact identity, successful loading, safe activation, authorization, and distribution-channel eligibility. Demonstrate both an accepted update and a correctly rejected one.
E.9 Stage 9: system engineering, data, and robotics
NASA’s systems-engineering material [127, 128] supplies requirements decomposition, traceability, verification, and validation. PROV and OpenLineage [74, 73] support source and execution evidence. For the cyber-physical branch, read Feedback Systems [137], ROS lifecycle and QoS design [133, 132], and selected hybrid-system and barrier-function material [134, 136]. Artifact. Connect a dataset authority, local mirror, and analytical projection with explicit checkpoints and provenance. Separately construct a simulated robot pipeline whose interfaces record units, frames, clock uncertainty, and freshness. Link a transport-delay assumption to a stopping-envelope requirement. Permit planning updates while preserving a separately controlled local safety mechanism. Completion criterion. Explain why an annotation does not verify calibration, why telemetry is not control-theoretic observability, and why a simulation result is not a safety certification.
E.10 Stage 10: implementation proofs and human–agent tools
Use Lean’s official text [126] to mechanize one small structural theorem. Study CompCert, IronFleet, seL4, and Anvil [146, 129, 130, 125] for different implementation/refinement boundaries. Dibia [157], SWE-agent, and the harness-engineering reports [118, 119, 120] cover orchestration and development feedback.
Artifact. Link a representation theorem to the graph store or validate a lowering result with a small checker. Build a bounded context query, a typed change proposal, isolated checks, and a review step. Protect verifier and policy definitions from the proposer. Compare matched development tasks with and without the additional graph context, including unsuccessful attempts. Completion criterion. Name the remaining trusted code and assumptions. Judge agent assistance by accepted behavior and review cost rather than output volume. Demonstrate that an instruction embedded in source text cannot authorize a protected operation.
E.11 An authoring and integration practicum
Study Unreal’s Blueprint introduction, technical guide, and debugger [1, 11, 12] alongside the Reaktor visual-language design [4]. Implement one reusable feature definition and two instances with different configuration. Give it a textual form, a visual projection, and a source-linked validation error. Distinguish generated implementation from the source that owns the declaration. Then trace that feature through Dependeasy/CLI target facts, a local test binding, one real service adapter, an artifact, and an observation [5, 20, 6]. The exercise is complete only when a contributor can identify what the framework derives, what an external tool executes, and what remains an application decision. A beautiful graph that cannot run or a successful build that cannot be connected to the selected feature is incomplete.
E.12 Capstone and priorities
The first complete project should be a shared-interface messaging feature with node-owned ports, a publication hyperedge, a scoped commit/deduplication protocol, a data projection, and a supported update region. Provide a local realization, a distributed realization, a deterministic failure harness, and a workbench view connected to the same source identities. The initial study spine is relational modeling, executable semantics, distributed state machines, and measurement. Category theory, advanced hybrid analysis, and proof assistants become most useful after a concrete obligation exists. Completion is not the number of books read or the number of graph primitives introduced. It is agreement between the specification, models, counterexamples, tests, measurements, and the behavior of a running system.
Original page layout, starting at page 109
F. Source lineage, maturity, and explicit design decisions
F.1 Documentary baseline
The reference stack is grounded in the Reaktor and BestBuds source baselines cited in References [9, 10], the public documentation sources under targets/reaktorWeb/docusaurus/docs, and the LiveUpdate memorandum [88]. The documentation audit enumerated 70 public routes from the site’s configuration, sidebar, manifest, and page sources. Private documentation was excluded. The deployed website and sitemap were unavailable to the audit, so correspondence between those sources and the current deployed website was not established. Public URLs in the references are discovery links; the pinned source inventory is the evidence baseline. The corpus is not one synchronized specification. It includes implemented-substrate reports, proposed architectures, product designs that assume framework completeness, alternative decompositions, critiques, and merged stubs. Claims of implementation are attributed to their source, not promoted to an independently reproduced current deployment. This manuscript reports no new Reaktor application build, mobile run, cloud deployment, or measured performance experiment. The finite generation explorer is the separately reproducible artifact described in Appendix D.
The companion source package includes a 70-route coverage/disposition map linking the audit to the sections of this manuscript. Index pages and merged stubs are not independent missing subsys-tems. Historical roadmaps and implementation schedules are not carried forward as current delivery commitments.
F.2 Maturity interpretation
Source category Interpretation in the manuscript
Source-reported An implementation or tested slice described by the cited code/report. It
implementation supports an engineering example, not a complete end-to-end assurance
claim.
Source proposal A design specified in a canonical module page. Interfaces and target
workflows are explanatory, not proof of availability.
Specification decision The architecture defined here, including stricter distinctions needed for the
port-hypergraph, assurance, and update model. Divergence from a source
proposal is explicit below.
Constructed study An application scenario designed to expose requirements, tradeoffs, and
potential benefits. No deployment or productivity outcome is implied.
Established result A result attributed to literature or an existing system, used only under its
stated assumptions.
Reproduced finite result Enumeration of the attached abstract generation model. Scope excludes
production memory models, migration, distributed rollout, and actual
runtime code.
The documented foundation includes useful graph composition, shared service interfaces, local actor execution, platform/store adapters, native bridge experiments, build conventions, and shared web/desktop workbench structure. The documentation separately marks important capability normalization, general Blueprint execution, full graph mutation/federation, bus/mesh composition, generalized Switchboard, UI host-tree interop, and LiveUpdate as proposed or incomplete [21, 22, 25, 26, 4, 27]. Fine-grained source status belongs in implementation release records rather than being inferred from the architecture’s use of a module name.
F.3 Decisions that must not be silently merged
Source tension Decision in this specification
Transport-bearing service Preserve shared service APIs, but separate operation/protocol identity from
types HTTP, Worker, FFI, and broker realizations (Section 11).
Binary consumer/provider Preserve the reference profile and node-owned ports; extend connectivity to
kernel role-labelled incidence occurrences and native hyperedges (Section 9).
Four FFI/RPC shapes Treat unary and streaming RPC as a bridge subset, not the complete universe
of port protocols (Section 22).
Graph, AST, and source Supported Blueprint source elaborates to an inspectable behavior graph. The
identity graph is not literally every arbitrary Kotlin AST, and generated
implementation is not a second manually edited authority (Section 5).
Flow-based determinism Push-exec/pull-data, Kahn networks, and synchronous dataflow are distinct
interpretations. Effects, state reads, bounds, and scheduling require their own
rules (Section 14).
Source tension Decision in this specification
All components as actors Use serialized ownership where state semantics require it. Pure operations
and supported stateless calls need not acquire mandatory mailboxes
(Sections 17, 22).
“Common/KMP” as a Common source sets, languages, execution domains, renderers, and
runtime deployment locations are separate axes (Section 4).
One update/security/UI Relate artifact, update, host-tree, runtime, and trust boundaries without
boundary assuming they coincide. Compatibility maps distinct revision counters;
compact slots are generation-local (Sections 22–27).
Automatic rollback Code rollback is allowed only when the current state and external-effect
contract permit it. Forward recovery can be necessary (Section 26).
Global data authority rule Default product profiles can be server-authoritative. Other profiles require an
explicit logical authority or merge algebra; no cache silently becomes
authoritative (Section 18).
Metadata as safety A capability label, signed bundle, actor type, or parameterized-query string is
not by itself an enforcement or isolation proof (Sections 20, 30).
GCP reference fleet Regional GCP/k3s cells are the documented reference architecture. The
generic provider model does not claim shipped support for every cloud
(Section 23).
Nexergy package The commerce/inventory/logistics and catalog/ledger/fulfillment
alternatives decompositions remain alternatives. Both illustrate reuse; neither is inferred
to be implemented (Section 33).
Server moderation and Server-readable processing and cryptographic server exclusion require
E2EE different product profiles. Their guarantees are not combined silently
(Section 20).
These choices retain the source corpus’s full-stack engine, composition, and tooling intent while defining the stricter semantics used in this paper. Unsupported zero-overhead, universal determinism, complete inference, and productivity claims from broad historical analyses are not adopted. They require a defined model or an evaluation before becoming claims of the system.