Graph composition, distribution and safe change
A complete system combines multiple kinds of computation and authority. The graph gives them identified contracts and relationships; each execution profile gives them operational meaning. Partitioning and code push are transformations of that identified system under constraints.
Execution profiles
| Profile | Scheduling/state rule | Boundary condition |
|---|---|---|
| Pure Kotlin computation | Ordinary function evaluation over declared inputs | Purity is a checked or trusted implementation contract; arbitrary code is not automatically pure |
| Local typed invocation | Bind a provider to a compatible consumer | In-process failure/lifetime rules; no implied durability |
| Actor | One declared mailbox/state owner with its ordering and supervision policy | Different actors need explicit coordination; local serialization is not consensus |
| Durable workflow | Checkpointed transitions and retry/reconciliation rules | External effects may have unknown outcomes or noninvertible compensation |
| Stream/dataflow | Demand, buffering, clock/window and loss contracts | A cycle needs defined scheduling/state semantics |
| Transaction authority | Conditional updates/atomic commit inside a named authority | Independent authorities need a coordination protocol |
| Native/device execution | Target-specific ABI, resource and timing profile | A JS graph host does not certify hard real-time or physical safety |
Different profiles can compose through typed boundaries. They must not silently inherit each other's guarantees. A service call to a workflow can return admission while completion happens later; a local borrow cannot be sent as a network pointer.
Partitioning as a constrained graph cut
A partition maps a legal region or node set to a host profile. For each crossing relation, preserve the participants, contracts and role slots; introduce the qualified boundary adapter needed by the execution profile. Check at least:
- Type/schema, ABI, serialization and compatible error outcomes.
- Ownership, lifetime and memory-domain transfer rules.
- Authority and facet visibility at the receiving host.
- Clock assumptions, latency/deadline, ordering and cancellation.
- State ownership, replica consistency, fencing and migration requirements.
- Target capabilities, resource budgets and artifact dependencies.
Optimization occurs after legality. A cost function can rank legal placements by latency, cost, locality or energy. It cannot make a borrowed pointer remotely valid or grant authority to a principal. H21 placement and H22 affinity/separation express constraints; they do not implement a scheduler.
See hybrid compute, partitioned actors, partition boundary and IoT buffering.
One change path for humans and agents
snapshot and bounded query
→ typed proposal and patch with base revision
→ normalize, structural validation and dialect checks
→ target/dependency/effect plan and fingerprint
→ authority and policy decision for that exact plan
→ target execution
→ observed reconciliation
→ receipt with revision, target, scope and unresolved outcomes
Agents can propose arbitrary Kotlin and graph changes. Their ability to generate a plan does not authorize execution, waive checks or approve their own release. Graph revisions, code artifacts, migration inputs and policy decisions must be bound to the same candidate. A changed candidate invalidates a decision for the older fingerprint.
The new structural definition checks are one stage of this pipeline. They currently validate identity/reference integrity and preserve incidence roles. They do not supply the full planner, admission authority or distributed publisher.
Activation, replacement and draining
A host publishes a candidate activation under a new epoch after its local admission checks. Calls already admitted under the old epoch retain that binding. The host needs an explicit rule for long-lived sessions, timers, borrowed buffers and callbacks: drain, cancel, coexist or migrate.
Per-host atomic publication is not a globally atomic rollout. A cohort can contain admitted, refused, unreachable, stale and unknown host states. The controller reconciles those observations under a declared mixed-version policy.
Mutable state changes are independently versioned and mediated at the state authority. Generation pinning alone cannot prevent old and new implementations from observing incompatible shared state. A migration must identify its source/target schemas, expected state version, fencing and recovery conditions.
Visibility and evidence
A graph snapshot is scoped by workspace, environment, principal, revision and time/cut. Hidden facets cannot become visible just because a query reaches the node. A redacted view can preserve topology only when its disclosure policy permits that topology.
Claims need origin, condition, scope and freshness. A theoretical result, declared contract, passing unit test, sampled runtime observation and production attestation are different evidence kinds. A claim-to-evidence hyperedge identifies support and its limitations; it does not transform a diagram into proof.
The telemetry and authorization examples keep these distinctions visible.