Operations integration. Operations & Reliability uses this canonical graph for telemetry selection, instance ownership, profiling and Shadow scope. Traces, aggregates and experiment journals are evidence projections and referenced artifacts; they do not become millions of active application nodes. Graph evidence defines identity, revision and coverage joins.

Reaktor Living Graph

The graph is Reaktor's common programmable structure for building and changing complete software systems. A feature can connect product UI, ordinary Kotlin, services, actors, native computation, storage, cloud resources, tests and agents. Developers can compose that feature, inspect its actual boundaries, execute supported behavior and follow an observation back to the source that produced it.

This is one heterogeneous, nested, multilayer logical port graph living through source authoring, build and runtime. Structural, behavioral, deployment, data, authority, test and observation layers are relations and interpretations of that graph. A Blueprint, a source outline, a deployment view and a trace are coordinated projections; none owns a competing system model.

Revision: 7 September 2026. This page is the canonical Living Graph foundation. The north star and roadmap place it in the product and release plan; the super-IDE atlas specifies the current workspaces. The contracts below are design targets unless the implementation baseline explicitly says otherwise.

11 September — the wire. Reaktor Graph Protocol implements this page's identity, provenance and command laws as an actual protocol: how separate runtime graphs connect into one mesh, how anything reads or changes them, and how a system running several deployed revisions at once is presented as several graphs rather than one averaged fiction.

8–9 September refinement: Data-oriented Substrate and Typed Maps develops this foundation into a proposed HLD and Kotlin contract set: pure graph data, typed capability tables, map algebra, bounded visitors, owned execution, channels, portable logic and a measured migration. Its complete ecosystem integration contract covers every framework module/build directory and desktop mode, with manifests, runtime hooks, observation cursors and shared Workbench context. It refines implementation choices while preserving this page's identity, ownership and truth laws; it is not a report of a replaced runtime.

1. One graph, many useful interpretations

The logical graph does not require one central database, one process, one scheduler or a globally replicated object heap. Definitions, build artifacts, local runtime scopes, cloud authorities and historical evidence remain with their owners. Typed identities, contracts and relationships let authorized queries and commands work across them.

A local Graph continues to own executable composition and lifecycle in its host. It is a runtime realization of part of the logical graph. A build manifest describes a definition revision; an activation identifies an instance executing that revision; an observation reports what a particular source saw. These are connected entities and facts in one identity system, rather than separate app, runtime and IDE graphs to keep manually synchronized.

The same declared relationship should do several useful jobs. A service binding can drive generated clients, source navigation, auth checks, tracing and deployment closure. An actor's ownership can guide state access, cancellation, debugging and restart. A capability requirement can select an implementation and identify fallback scenarios. A module can contribute all those mechanisms through normal APIs and an opt-in graph projection.

The graph earns its place by reducing repeated glue and making more complex behavior expressible. It must remain usable for a small app, a custom Kotlin subsystem and a large existing system with opaque boundaries.

2. Structural and semantic laws

A graph is not automatically correct because every object has a node. Useful guarantees come from the laws of selected mechanisms, complete enough boundaries and evidence for the actual implementation.

3. Implementation baseline

The September source contains substantial substrate and several models that still need integration. This design does not report new runtime or deployment tests.

Code anchors include reaktor-graph/.../core/Graph.kt, reaktor-graph-port/.../visitor/Visitor.kt, reaktor-flow/.../document/GraphDocument.kt, GraphEditorSession.kt, reaktor-cloud/.../WranglerInventoryProvider.kt and reaktor-compiler/.../ReaktorProcessor.kt. The system map maintains release progression.

4. Logical model and distributed ownership

The model has a small structural nucleus: entity identity, typed endpoint, typed relation, boundary, facet, revision and change. Domain modules give those structures meaning. Storage, indexes, compiler IRs and render scenes are representations of selected parts of this model.

A project service can index definitions and cache authorized runtime/provider facts. Runtime islands retain their own local graph and executable resources. Provider adapters preserve their systems of record. Queries obtain a scoped snapshot or follow a change stream; no island must load every resource, invocation or historical event.

The graph includes:

• Definitions: modules, features, functions, components, ports, schemas, actors, protocols, resources and operation declarations.
• Revisions and artifacts: source versions, normalized definitions, generated bindings, binaries, build manifests and configurations.
• Activations: running instances, actor epochs, sessions, installed instrumentation and selected bindings.
• Events and evidence: commands, turns, calls, observations, tests, profiles, counterexamples and reconciliation outcomes.

Relations such as contains, requires, binds, realizes, invokes, ownsState, placedOn, derivedFrom, observes and validates connect those entities. Definition and activation membership need not be identical: a factory definition may produce many activations, and a stopped instance may remain visible through its history.

Identity and consistency domains

A stable definition ID names a semantic declaration independently of its file location. A revision identifies a particular definition content. An activation reference includes its host/session and epoch; a late completion cannot acquire the identity or authority of a replacement instance. A build artifact links back to the definition/source revisions and toolchain inputs that produced it.

Renames and moves preserve identity when the owning adapter can prove the correspondence. Copies create new identities. Splits, merges and extraction operations produce explicit remapping records. Name equality, similar source text or equal schemas do not by themselves prove that two services are the same entity.

A structural commit is atomic only inside its declared consistency domain. A federated query may carry a vector of source revisions, host epochs, event cursors and provider observation times. It must not pretend that independently sampled facts are one global instantaneous snapshot.

5. Nodes, ports, relations and semantic layers

A node is an extensible semantic entity with typed facets, not a mandatory subclass of one universal runtime class. A route, pure function, actor, database interface, deployment, domain concept or test may all participate. Some execute; some declare; some record evidence. The kind and supported semantic interfaces explain the difference.

Ports expose contracts with direction, role and interaction shape. Value, state, request, stream and mailbox are useful public shapes. Each additionally states ownership, lifetime, errors, cancellation, ordering, delivery and relevant capability/effect requirements. A state port provides a view of its owner's state; it does not confer mutation access. An in-process object reference does not become a safe remote contract merely by receiving a port label.

Contract identity names the contract. Compatibility checks the applicable schema/version, direction, cardinality, ownership, effects and runtime profile. A conversion is an explicit adapter with its own obligations, rather than proof of subtyping. A legacy erased-type fallback cannot silently authorize a stronger cross-language connection.

Layers are composable semantics

These layers can share nodes and relate different node families. They are not a fixed sequence of app, service and cloud graphs. Containment is usually a tree for a specific ownership relation; dependency and invocation may contain cycles; dataflow and choreography use the laws of their chosen profiles. An algorithm must state which relation it traverses.

Canonical dependency relations name consumer and provider explicitly. A data-flow projection may draw values provider-to-consumer, while a dependency query walks consumer-to-provider. Arrow direction in one view must not reverse the underlying meaning unnoticed.

6. Kotlin, source and build-time participation

Kotlin is the native authoring language and keeps its full expressive power. Developers can use ordinary functions, classes, loops, higher-order abstractions and custom DSLs to compose modules and implement behavior. Reaktor does not require all useful code to become a finite node language.

Turing completeness is a design requirement of the general Kotlin/behavior profile, in the usual language model with unbounded available memory and execution. General loops, recursion and dynamic data structures must remain expressible, through reified control/data/state or code-backed computation in the same logical graph. Finite DAGs and bounded protocol models are restricted verification/execution profiles; they do not cap the general graph language. Actual targets have finite resources and explicit execution budgets, and a small bounded-Int example is not itself a proof of this requirement.

That freedom creates an explicit analysis boundary. Arbitrary Kotlin can construct different structures from inputs, invoke external code or fail to terminate. No general extractor can statically enumerate every possible runtime graph or prove every arbitrary implementation. The model therefore combines exact declared structure, supported compiler/source facts, explicit dynamic factories and observed activations, with coverage stated for each region.

Supported authoring forms

A Kotlin-first project can generate owned provider configuration and clients. A brownfield project can retain Pulumi, wrangler, Kubernetes, SQL or other authoritative files and contribute mappings through adapters. “One graph” does not require replacing every configuration language with a Kotlin file or making inferred topology authoritative.

Build-time work can extract declarations, validate a decidable contract subset, compute dependency closure, generate codecs/bindings and package manifests. Executing an arbitrary application to discover its graph is not a pure compiler pass. Discovery that evaluates code uses an explicit environment, inputs and effect policy; a manifest records which profile and inputs produced it.

Source/visual round-trip

Every semantic region names an owner and supported edit operations. A visual connection can generate a source edit only where its adapter understands that construction. Ordinary source remains available when visual mapping is incomplete. Preserve comments, formatting, custom expressions and unrelated code; do not regenerate an entire arbitrary Kotlin file from a lossy diagram.

Generated Kotlin is an artifact when a reified region owns the source. Hand-authored Kotlin is the owner when the graph is extracted from it. A migration between those modes is explicit. Two independently editable owners for the same semantic region are a conflict, not automatic bidirectionality.

The visual language defines behavior-region authoring; Graph Sources defines ingestion and correspondence.

7. Live facts, snapshots and freshness

A living graph can be stale, partial or disconnected. Its advantage is that it can identify those conditions and preserve useful context, rather than conceal them.

A fact records its subject, owning source, source revision or activation, observation/query time, applicability and evidence. Authored, extracted, observed and inferred are origins, not a single ranking of trust. Assurance method, freshness, coverage and operational condition remain separate dimensions.

A subscription starts from a scoped snapshot plus a cursor and receives versioned changes. Duplicate events are handled by identity. Missing events, expired cursors or out-of-order updates trigger resynchronization or a marked partial result. Coalescing is valid only when the event contract preserves enough information for the consumer; dropping intermediate events cannot silently maintain a complete audit or actor replay.

A provider failure marks that provider's facts stale or unknown while retaining their last observation. Desired-only and observed-only resources stay visible. Drift compares facts that actually refer to the same entity and compatible scope; two snapshots from different environments are not a drift comparison.

A pinned trace keeps its artifact, activation and recorded time while the project moves to a new source revision. A live editor can follow current observations independently. Refreshing the target selector must not relabel historical evidence.

8. Runtime islands and computation profiles

Runtime islands are executable, lifetime and failure boundaries: a device process, browser, Worker, JVM service, native library host or supported remote worker. Storage resources and external services participate through their own authority/profile; displaying them as an island summary does not assert that they host an arbitrary Reaktor actor.

The graph supports multiple computation profiles through modules:

A DAG planner is useful for an acyclic dependency subset. It does not describe every workflow, recursive program or stream. A local actor is not automatically durable, and a durable record does not by itself implement transactional inbox/state/outbox, deduplication or timer recovery.

The graph remains alive while hot execution specializes. Stable regions may lower to direct calls, coroutine code or native kernels; metadata, mappings and probes retain the supported connection to the logical graph. Reaktor need not dispatch every arithmetic operation through a reflective graph interpreter.

A deterministic snapshot or traversal does not make application execution deterministic. Replay requires a named profile with controlled or recorded inputs, clocks, randomness, scheduling and effect outcomes. Trace inspection, simulation and re-execution are different operations.

JS targets may export manifests through ordinary supported host/transport mechanisms. Hermes/FFI is a valuable owned-host profile, not a universal prerequisite for browser or Cloudflare discovery. An export contract must be independent of the transport used to obtain it.

9. Service, provider and FFI boundaries

A service connection relates a logical ServiceAPI/operation contract, a consumer, a selected implementation and a selected binding. Matching contract names finds candidates; it does not prove that traffic uses one of them. Environment, endpoint/binding configuration, principal scope, runtime profile and observed correlation establish the applicable connection.

The graph should expose the complete cut:

• service identity, request/result/error schemas and version compatibility;
• selected host/provider and transport, including local calls, HTTP, service bindings, queue adapters or FFI;
• authentication context, authorization mediation and effect scope;
• deadline propagation, cancellation versus completion, retries and operation identity;
• ownership of state, arguments, buffers and returned resources;
• source configuration, deployment artifact and observation coverage.

Across an FFI cut, buffer ownership, borrow/retain/copy rules, runtime-thread affinity, credits, cancellation and close barriers are semantic facts. A cancelled request can still have an external outcome to reconcile. A port connection cannot imply zero-copy, exactly-once effects, safe native isolation or parity across transports.

The opinionated reference stack is part of this graph: Cloudflare Workers, compatible Durable Object profiles, R2, D1, Queues and optional Realtime/TURN; GCP/k3s and Pub/Sub; PostgreSQL domain authority; ClickHouse and Memgraph projections; Firebase and distribution; Grafana/OTel and tools. Each adapter contributes concrete operations and limitations. A small app uses the subset it needs.

Coverage matrix — what the map may claim today

The map labels each system with the strongest status its code supports. Source means configuration or module code binds it; observed means code reads live state or evidence at runtime; designed means only a document describes it. The 7 September 2026 source audit of both repositories established the following; the map's district status lines and the Bus/Mesh boards use these labels verbatim.

For each datum, name one write authority. R2 object publication, a PostgreSQL transaction, a queue acceptance and a derived analytics update are separate outcomes unless a declared protocol establishes stronger coordination. Do not invent atomic publication across them. See Service, FFI, data/cloud design and actor semantics.

10. Visitors, passes and useful graph power

Visitors are pure, bounded interpretation over selected immutable inputs. A pass packages selection, traversal, dependencies, versioned result schema and declared assumptions. Analysis, rewrite proposal, observation installation and runtime execution have distinct contracts even when the same command registry exposes them.

A traversal declares relation types, direction, boundary policy, ordering, path/context sensitivity, visit multiplicity, cycle handling and work limits. “Visit each node once” is sufficient for some inventories and wrong for path-sensitive policy or protocol analysis. A result can include witness paths, excluded boundaries, incomplete inputs and the smallest counterexample.

A complete feature is the unit of composition

Consider a Fieldwork capture feature. Its UI requests camera access, chooses an available capture/processing strategy, calls a native or Kotlin transform, records an upload intent, submits through a service and observes a stored result. The same feature definition links its device capability, owner/state protocol, FFI buffer contract, cloud placement, auth mediation, tests and outcome instrumentation.

A developer can build it through one connected sequence:

1. Compose from a port. Select MediaStore and find eligible module/provider implementations. Inspect the exact protocol and add a named binding; a missing implementation remains a typed hole in a saved draft.
2. Choose a strategy. Compare on-device processing with Worker/JVM processing under target support, privacy, latency and cost constraints. The proposal includes source, UI fallback, buffer/data movement, provider configuration and tests, rather than changing only a dropdown label.
3. Extract an engine component. Turn the chosen capture/upload region into a reusable definition with explicit boundary ports and per-instance state. Update callers and keep both reusable-definition and call-site source maps.
4. Exercise the protocol. Run a fixture with a delayed acknowledgement and duplicate completion. Inspect the actor turn, intent/effect identities, native lifetime and service receipt. A finite protocol check can produce a counterexample while arbitrary implementation code remains testable source.
5. Change and deliver. Review the graph/source delta and affected closure, run the relevant native/client/service checks, build the exact artifact, prepare provider deployment, then correlate an observed execution with that revision.

This is a proposed acceptance journey, not a claim that the fixture's durable protocol or every adapter is implemented. It demonstrates why shared graph semantics add expressive power: composing a module changes a connected feature across its implementation and tools.

Breadth without a different kernel for every application

The kernel application cases remain an important design test. The same primitives should support more than infrastructure inspection:

A domain author can add a meaningful node/relation vocabulary without writing a new graph store. An engine author can attach compilation, analysis, provider adapters and specialized instruments to that vocabulary. The core remains small because behavior lives in lawful contributions and selected runtime profiles.

Incremental results need a contract

A cached result names its read set, complete input revision/time vector, pass/profile version and assumptions. An incremental update must equal a fresh analysis for the same complete input, or invalidate the result. A changed policy, unknown dependency, lost event or omitted region cannot retain a green result by convenience.

Use consistent snapshots for claims requiring a consistent cut. Sampling each node's mutable collection separately may support a labeled exploratory view; it cannot establish a global no-cycle, full-coverage or compatibility result. Parallel analyses are useful; rewrites need semantic conflict checks across their read/write assumptions.

A telemetry installation or auth wrapper is a prepared runtime change with owned lifetime and effect policy. Pure traversal can propose it, but does not perform the external work. Adding retries, caching or relocation can change effect multiplicity, freshness, principal scope and failure behavior; those transformations need stated preconditions and evidence.

See Graph Visitors for the pass API and Formal Methods for the assurance portfolio.

11. Scope, layers, detail, time and editing mode

The workbench must make five independent choices explicit:

Use a composable ordered layer/query stack, not one mutually exclusive lens enum. For example: select Media Messaging, include dependencies and selected bindings, expand one FFI boundary, overlay auth coverage, add a pinned trace and compare a candidate placement. Source and Blueprint editors can remain open alongside the result.

Layer order is explicit where transformations depend on earlier results: filter, expand, group, aggregate, analyze and decorate do not always commute. Each layer declares its inputs, output kind, identity/witness mapping and supported interaction. Pure display decoration cannot change the semantic query. Hiding an edge is not deleting it; grouping is not extracting a module.

A collapsed node or portal retains the identities and witness paths it summarizes. Selecting it can reveal the exact members, omitted coverage, contract and owning boundary. A deployment grouping may overlap a feature scope; it does not reparent source ownership. A domain concept map can be authoritative for domain knowledge while linking to implementation, with its own editing contract.

Persistent tabs, split editors, Project/Structure, Details and tools use the same references. Details can follow or pin. Saved perspectives retain arrangements and filters; they do not silently change authority or retarget historical runs. See hierarchical graph UI and the atlas.

Continuous semantic zoom: the whole system remains one place

The intended experience is like navigating a map from Earth to cities to streets: fleet/application → runtime island → feature/composition → node → port and invocation, continuously inside the same workspace. These are useful presentation bands over one graph. They are not separate graphs, page destinations or mandatory hops in an architecture wizard.

At a wide scale, a runtime island or feature appears as a region with exported interfaces and meaningful summaries. Zooming into it progressively reveals components, ports, behavior, selected state and source correspondence. Zooming out replaces those details with exact aggregates while preserving the selected entity, named route, layer stack and time context. A route can remain highlighted across client, native, Worker, database and notification/analytics regions even when most internal nodes are folded.

The implementation can quantize detail into practical rendering bands, with hysteresis to avoid flicker, while camera movement and navigation stay continuous. A multiscale index retrieves summaries and detail lazily. Aggregate/view IDs map to the canonical member IDs and boundary endpoints; an aggregate is not a new application entity. Manual pins and stable local layout preserve the mental map. Source, graph, preview and trace selection remain synchronized through canonical references rather than screen coordinates.

Scope controls query domain, authorization and work budget independently of the camera. A developer can pan or zoom through a whole authorized system without opening a new page for every child, or deliberately focus a small region to run an expensive analysis. A chosen route can include relevant off-screen context beyond the local detail window. A visible indicator distinguishes folded, unloaded, filtered, redacted and unknown coverage so that rendering fewer objects does not imply a smaller system.

Districts, corridors and bundles keep one graph

The system map presents the estate as districts — runtime or provider domains such as the client fleet, the Cloudflare edge, the domain authority, derived views and delivery — with corridors between them. Both are projections. A district groups nodes by a stated basis (runtime island, provider, data authority); changing the basis regroups the picture and never changes ownership, and a feature can span several districts. A corridor is a bundle of member relations: one road with a member count that resolves, on selection, to its exact source and destination ports, its multiplicity, the selected members and its branch points. Where a route enters or leaves a scope it terminates on a portal, the real boundary port, never on a container edge; members that leave the viewport are named as offscreen continuations with their counts.

Every road keeps its class (value, state, request/result/error, mailbox, FFI call or stream, Bus, Work, Mesh, data write or projection, build/activation) at every scale; the grammar is specified in Visual Language. Return, error, retry and completion paths are drawn, not only the forward arrow; cycles, fan-out, joins, dynamic actors and long-running streams remain representable because a finite DAG is only a restricted profile. A route is shown as declared, candidate, simulated or correlated; a correlated road ends at the observation cursor and continues as unknown.

Explain view is the contract behind every count. It reports the ordered query stack (scope → structure and contracts → filter → expand → decorate) with each step's input and output, the folded and omitted members with witness paths, the budget and truncation, and the states of what is not drawn — hidden by a layer, not loaded, stale, inaccessible, unknown. Denominators are visible / scoped / known / unknown and exclude restricted objects instead of leaking them through aggregates. Reordering decorative layers changes nothing; reordering filter and expansion changes the result and is shown. Placement defaults to logical topology; physical geography is an optional overlay that needs location evidence, because ownership, provider placement, failure domain, data authority and locality overlap and cannot be forced into one containment tree. The interaction contract lives in Graph Navigation; the four authored states are in the atlas.

Named routes and end-to-end flow selection

A graph route names a navigable typed relationship selection through the system. It can start from a UI event, operation, state change, resource, requirement or diagnostic and follow selected dependencies, calls, actor messages, returns, events, notifications or data projections. This is distinct from a UI router's navigation route. A route definition contains its entry/exit interests, relation/profile filters, branch policy, source revision and saved view preferences; a selected execution adds invocation, correlation and causal evidence.

Routes need not be simple paths. A capture journey can branch into local state feedback, remote upload, report publication, a notification and asynchronous analytics, then include return/error/retry paths. The route inspector keeps those branches and their completion criteria explicit. A service call, FFI invocation, queued message and event-subscription relation share typed graph navigation, but retain different timing, scheduling, delivery and failure contracts. A road-like visual connection is not a promise that all transports are interchangeable or asynchronous.

Selecting a named route highlights exact member edges and ports at the current scale. Folded regions show route entry/exit portals and branch membership. Expanding a portal reveals its preserved internal endpoint mappings; zooming out retains the same route. “Follow execution” advances using a selected run's events and known cause/correlation links, not an animation of possible topology. A declared path, simulated scenario, recorded run and live observation are separate route modes that can be compared.

The result is a common navigation instrument for product work: show everything this action touches, show the state that feeds this UI, show where this datum leaves the device, show the failure and retry route, show what a provider replacement changes. The query returns witnesses, not merely a set of highlighted boxes.

Inspect a UI element into the full system

Inspecting a DOM element or Compose/render node should highlight its source/component instance and expand its relationship to the complete feature: rendered element → binding and handler → graph operation → actor/service/protocol → state/effects → dependencies and resources → resulting UI and downstream events. The developer can move in either direction: select the button and reveal its upload path, or select a state field or service outcome and reveal the UI it affects.

The host adapter supplies a selection bridge: application/artifact revision, host/render epoch, element-instance identity, component definition and instance path/key, supported source locations, bindings/handlers and instrumentation coverage. A reused component distinguishes its definition from each rendered instance. The bridge should survive ordinary rerenders where the host's identity rules permit it; a DOM selector or pixel coordinate alone is not durable semantic identity.

An element may have several bindings, delegated event handlers, parent propagation or several source locations. A generated wrapper may lack a direct source span. An external/opaque widget may reveal only its boundary. The inspector exposes these mappings and lets the developer choose the relevant event/handler; it does not guess one authoritative path. Clicking Inspect selects without firing the product action. For an observed interaction, the chosen event/run adds the actual invoked path and state outcomes.

A UI-origin route remains selected as the graph zooms from a button's port to the complete distributed system. Source opens alongside the graph, exact endpoints remain inspectable, and the developer can attach the same element, route and evidence package to Claude/Codex. A patch that changes the handler, binding or data schema links back to the source, graph and affected preview rather than leaving three disconnected edits.

12. Commands, commits and runtime change

A command names its operation/schema, targets, base revisions, context, read/write assumptions, effect class, required capabilities and authority, and expected results. It may be invoked by a gesture, source action, CLI, agent or custom tool. Applicability depends on a supported handler and actual scope, not merely whether a node was learned natively or by scanning.

Keep the following transitions distinct:

Local structural edits can be transactional. External effects, multi-provider deployment and arbitrary initialization cannot be rolled back by restoring a graph document. Recovery uses the declared compensation, restore or roll-forward profile; some outcomes require investigation.

Concurrent changes compare both writes and assumptions. Renaming a contract can conflict with a generated client change even if files do not overlap. Rebase re-resolves identities, checks remappings and invalidates affected plans/evidence. A layout CRDT may be useful; it does not make conflicting state ownership or deployment changes mergeable.

Runtime lifecycle distinguishes definition, preparation, publication, activation, drain and close. Host stop events are not guaranteed. A supervised shutdown contract can order cleanup during a functioning process; it cannot promise callbacks after process death. Restart and replacement create new epochs and fence stale work. Live reload, topology reconfiguration, code replacement, state migration and distributed rollout qualify separately.

Orchestrating a selected end-to-end flow

Orchestration composes headless and interactive software from any admitted trigger. It is a general graph capability: HTTP/webhooks, queues/state changes, timers, devices, CLI/operators, agents and protocol continuations can drive the same native flows as UI events. No screen, button or browser is needed.

A named graph route becomes executable only through the selected computation/protocol profiles and supported operation adapters. Reaktor can orchestrate a complete flow by composing those profiles: prepare device/native inputs, invoke a service, advance owned actor/protocol state, wait for declared outcomes, run a downstream task and reconcile target results. This is more than visual tracing, but it does not introduce one global scheduler over independent systems.

The route runner exposes a versioned flow plan: entry inputs, selected definition/artifact and bindings, prerequisite work, fixture substitutions, state origin, target placements, grants, time/cost/resource budgets, effect identities, wait/timeout rules and branch/completion conditions. The plan lists which segments will execute, simulate, observe or remain external. Pure local work can run immediately under the existing grant; an external operation uses its actual effect and authority policy.

Control applies to the relevant unit of work. Pause a supported local debugger or stop admitting new work; drain the selected actor/worker scope; cancel an invocation under its protocol; resume from a durable checkpoint only when that profile supplies one; reconcile an unknown provider outcome using its operation identity. A resumed flow must not blindly repeat an already-committed effect. A non-resumable segment offers restart with stated consequences rather than a fake universal Resume button.

Useful compound commands include simulate this route offline, run only this transform with pinned input, exercise the auth-denied branch, replay the lost-response counterexample, drain and replace this supported binding, and compare this route before and after deployment. Each produces a plan, observations and source-linked findings addressable by both people and agents.

Entry and admission contracts

Orchestration is trigger-independent. Headless flows are first-class graph programs with no UI wrapper required. A UI event is one important entry, alongside service requests, webhooks, messages, schedules, sensor streams, operators, agents and lifecycle/protocol continuations. Every entry uses the same typed graph, command contracts and selected computation profiles.

An extensible entry/admission registry connects a trigger source to the target operation or protocol. It records input schema and mapping, event/message identity, correlation, principal/grant context, admission acknowledgement, ordering, concurrency, buffering/backpressure, deadline/cancellation and retry/deduplication rules. The adapter states which guarantees are provided by its source or target. A transport acknowledgement, admission into an actor, committed business effect and published result remain distinct outcomes.

A flow may join an already-running actor, stream or distributed protocol, have several entry points, produce multiple outcomes or remain active indefinitely. Its lifecycle need not be “start a finite DAG, return one result.” Named profiles specify allowed transitions, progress, ownership and termination/completion where applicable; arbitrary source-backed computation remains available.

A runbook/flow asset owns reusable entry definitions, typed parameters and mappings, selected composition/profile references, target/environment bindings, budgets, checks and recovery procedures. It can be edited in source or a supported visual projection, versioned, reviewed and invoked from a trigger picker, CLI, agent or service. Credentials remain references to existing secret authorities. The asset does not copy the underlying program into another graph store.

What this makes possible

The public foundation should prove a useful headless trigger-to-outcome flow and a UI-to-system route through the same contracts, continuous zoom through their summaries and ports, concrete execution and a reviewable repair. Broader fleet navigation, profile orchestration and automated optimization grow from that same interface rather than requiring another graph or product mode.

13. Humans, agents and programmable tools

Humans and AI use the same query and command contracts, while effective grants and execution environments can differ. Claude/Codex and Conductor complement the graph: they can explain, propose, program and test through its typed boundaries. A special agent API must not become another source of semantic state.

Useful machine operations include scoped query, detail, explain-path, compare, command applicability, propose/rebase, validate, run and reconcile. Responses expose stable references, input versions, witness paths, findings, uncertainty and next applicable commands. They can be concise without discarding the evidence needed to inspect a conclusion.

An agent can ask “what changes if this feature works offline?” and receive proposed state ownership, capability strategy, service/FFI cuts, data authority, scenarios and build/deployment closure. An auth pass can return a counterexample path rather than a generic red badge. A blast-radius query names direct effects, dependent assumptions and uncovered regions; lack of known edges is not proof of no impact.

Routine edits and checks proceed under existing grants. Additional approval is conditional on the operation, environment and configured policy. Read-only tools can still expose sensitive data. A model, successful review or native-source label never supplies ambient authority. Conductor tasks, context attachments, findings and outputs remain linked to their selected graph/source revisions.

14. Authority, provenance and evidence

Authorization, source authority and evidential confidence answer different questions. A scanner can provide precise source locations while lacking a deploy handler. A wrapped service can expose a callable contract without permission to call it. An authorized developer can edit ordinary source even when the graph's extraction coverage is incomplete; the command must retain that limitation.

Separate public contract/schema information from protected instances and data. Queries enforce scope before returning names, counts, paths or summaries. Aggregate results must not leak hidden objects. Credentials remain in their existing secret systems; the graph stores references and applicable policies, not secret values.

Evidence binds a claim to a revision, profile, inputs, method, assumptions and coverage. A finite model check, unit test, native device run and production observation establish different things. A model result becomes relevant to an implementation through a stated conformance mapping and replay. A source change expires dependent evidence unless preservation is established.

Operation records include principal/delegation, target and environment, command version, input/plan identity, time, artifacts, outcome and reconciliation. A record that a request was dispatched does not establish its business effect. Auditing and masking are part of the same tool contract, not UI-only conventions.

15. Foundation delivery and the full-power horizon

December 2026 should qualify a useful integrated slice of the graph across creation and continued development. It should not wait for universal static extraction, all providers or arbitrary hot replacement.

Use BestBuds media messaging, Fieldwork capture and one brownfield/Manna-style domain graph to pressure-test different shapes. Select held-out features, not only the fixtures used to implement the adapters. Keep ordinary public library adoption viable through graph-agnostic APIs.

Beyond that foundation, expand reusable passes, language/source adapters, actor/durable profiles, graph-aware UI composition, protocol authoring, provider tools and optimization. General Kotlin remains available throughout. Formal methods improve selected laws and decidable subsets; they do not cap what applications may compute.

16. Scale, usability and failure tests

The model can describe a large system without keeping the whole system on the screen or downloading it to one client. Partition indexes by owner/project/host and authorized scope. Use paged queries, bounded neighborhood expansion, incremental summaries and observation retention policies. High-volume events or domain records may live in backing stores with typed references and query access.

The engine should preserve the developer's mental map as the graph changes. Apply local scene patches, retain stable positions and manual pins, and show incoming changes without moving a selected target unexpectedly. Full layout is an explicit operation or a necessary response to structural change. Virtualize cards/rows, separate graph computation from UI work, and cancel obsolete queries.

Publish workload-specific budgets for initial useful view, interaction latency, query/pass work, memory, event backlog, layout churn and source/trace navigation. Set those budgets against real hardware and representative graph shapes; node count alone does not describe complexity. Unknown provider latency must not freeze local editing.

Acceptance should include:

1. Cyclic dependencies, nested ownership, overlapping feature/placement groups and foreign opaque nodes in one graph.
2. A rename/move, factory-created activations and a stopped activation whose history remains addressable.
3. Continuous world-to-port zoom, layer reorder, hidden relation, boundary summary and witness expansion without semantic mutation or lost route identity.
4. Missing subscription events, provider disconnection and conflicting time vectors without false freshness.
5. Concurrent semantic changes, remapping/rebase and invalidated evidence.
6. A mutable-state loop that defeats naive memoization, actor cancellation races and an external outcome unknown.
7. A service with two compatible candidate providers where only one selected binding is active.
8. The same granted command invoked by a human, agent and custom tool with equivalent semantic results.
9. Large scoped views with stable selection, keyboard access, text scaling and accessible outlines.
10. DOM/Compose element selection through multiple or missing handler mappings into one end-to-end route, and reverse navigation from state/effect to affected UI.
11. A route with send, return, notification and analytics branches; follow one recorded invocation while preserving partial causal evidence.
12. A route run/resume/drain plan that preserves completed-effect identity and does not restart unrelated external work.
13. A headless webhook/queue/timer entry joins an existing protocol or stream, preserves event/correlation/admission identity and produces several qualified outcomes without a UI wrapper.

17. Module and repository responsibilities

Existing GraphDocument, architecture snapshots, runtime exporters and provider inventory have consumers. Map them to the common semantics with versioned adapters and conformance tests; do not rename every model or migrate every user at once. A wire schema can remain compatible while its ownership and projection role become precise.

A module contribution includes its ordinary API, graph vocabulary, source mapping, supported profiles, commands, queries/passes, runtime adapters, instruments and conformance cases as applicable. Adding an editor or visitor must not require a private parallel graph or privileged bypass.

18. The graph should make the next change easier

The destination is a development environment where selecting a feature connects composition, source, behavior, runtime, cloud, evidence and AI work. The graph survives build and execution as the shared structure and identity model, while each host executes efficiently and each authority retains ownership.

The developer can stay in ordinary Kotlin, descend into a native kernel, compose a reusable module, inspect a live actor or ask an agent for a tested change. Those are different ways to work on the same system. Reaktor's advantage grows when each added module and integration contributes more useful relationships, operations and evidence to that common graph.

Research basis and limits

The following sources inform this design; their results do not automatically prove Reaktor's broader model.

• Hierarchical port graphs: Ene, Fernández and Pinaud describe attributed hierarchical port graphs, constrained boundary mappings, flattening and a single-pushout rewriting account. Reaktor can adopt the discipline for selected executable regions. Arbitrary cross-layer relationships in the complete Living Graph do not necessarily satisfy that paper's hierarchy restrictions, so its proofs do not transfer by calling Reaktor a superset. Attributed Hierarchical Port Graphs and Applications.
• Checked transformations: DPO rules distinguish matched, preserved and replaced structure and require application conditions such as avoiding dangling edges. This motivates explicit matches, preserved interfaces and deletion checks in Reaktor. A checked typed delta should not be called a formal DPO implementation until its graph category and conditions are specified; structural validity alone does not prove behavior preservation. Söldner and Plump, Formalising the Double-Pushout Approach.
• Programmable graph strategies: strategic port-graph rewriting gives explicit control over where and how rules apply. Reaktor's proposed select/match/check/transform/validate commands draw on this separation; an agent can propose parameters while the same engine checks human and agent changes. Strategic Port Graph Rewriting.
• Execution profiles: static scheduling results for synchronous dataflow require declared token rates. Reaktor can exploit such properties for a supported stream profile without imposing them on arbitrary Kotlin, actors or cloud calls. Lee and Messerschmitt, Static Scheduling of Synchronous Data Flow Programs.
• Incremental computation: differential dataflow illustrates maintained computations with partially ordered logical versions and indexed changes. Reaktor should begin with measured indexes and dependency invalidation; adopting a specialized incremental engine requires evidence that its benefit exceeds its cost. Differential Dataflow.
• Bidirectional editing: lenses formalize source/view update laws on stated domains. They motivate tests for supported source-edit adapters, not a universal lossless inverse for arbitrary Kotlin. Combinators for Bidirectional Tree Transformations.
• Provenance: PROV-O distinguishes entities, activities and agents and supports qualified derivation. Reaktor can preserve source revision, extraction activity and observations using similar distinctions. Provenance records explain origin; they do not alone establish truth, current deployment or permission. W3C PROV-O.

The interaction design also learns from Unreal's separation of visual collapse, functions and macros, and its selected-object debugging; from dataflow systems' explicit input readiness; and from concrete input/output and fixture tools. These inform Blueprint authoring and graph navigation, with Reaktor's source, authority and runtime boundaries stated independently.

Related docs

• Graph Kernel — small structural vocabulary and application-shape acceptance matrix.
• Graph Visitors — bounded traversal, analysis and transformation contracts.
• Graph Sources — ingestion, correspondence, source ownership and coverage.
• Visual Language — executable behavior regions and source/visual authoring.
• Hierarchical Graph UI — scope, layer stack, detail, portals and live scene behavior.
• Component Lifecycle, Actor Model, Service, FFI — runtime mechanisms and their boundaries.
• Formal Methods, Control Plane, Product Atlas — verification, shared operations and current interaction design.