Shadow, evidence and region releases
Design synthesis, 7 October 2026. This chapter incorporates the supplied Astra report. Its models and acceptance tests describe intended architecture; they do not certify current implementation. The report inventoried 140 public routes and compared substantive sections of 51 documents. Repository source and current qualification receipts determine what ships.
Architecture thesis and invariants · Nodes, ports and hyperedge vocabulary · Composition and execution semantics · Compiler, source publication and consistency · Shadow, evidence and region releases · Authoring and industry precedents · Cross-runtime systems and worked scenarios · Impact, design obligations and qualification
11. Shadow, claims and evidence
Reaktor’s strongest potential is a closed change loop: propose a typed edit, calculate obligations, run a pinned candidate against qualified state and faults, promote the exact approved artifact vector, realize it, and join the observed outcomes back to the same identities.
FoundationDB’s simulation architecture is an important precedent because the paper’s authors report that simulation made risky subsystem changes more feasible, not merely faster to test. That supports the qualitative hypothesis that better experimentation can expand what a team is willing and able to build. It is not evidence for a particular Reaktor productivity factor. [FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)]
Shadow must distinguish contract assertions, baseline comparisons and live observations. Sampling is not replay completeness. Duplicate observers must not produce duplicate substitutions. A recorded AI output can validate orchestration but cannot measure a new model’s quality. Changed artifacts or policies invalidate approval according to a sound dependency model. [Shadow foundations] [Capture and replay] [Shadow verification and capsules] [Operational graph evidence]
Immutability also does not mean retaining sensitive payloads forever. Keep controlled artifact references, scope disclosure, retention and revocation policies, and suppression information so a rebuilt workspace does not resurrect erased records. Captured text is untrusted input to agents and must not rewrite the policy used to approve those agents’ changes. [Shadow workspaces] [Shadow verification and capsules]
Cross-document contract obligations
Capabilities: the current capability API presents a tier enum and additional attributes; the roadmap asks for multidimensional offers and constraints. Preserve the latter as the semantic model. A “higher tier” remote model does not dominate a local model when privacy prohibits transmission. Resolve hard compatibility, authority and placement constraints first; only then optimize preferences. Pin running sessions or define migration and hysteresis so adaptation does not create oscillation or resource churn. [Capability selection] [Reaktor plan and roadmap]
Evidence: Formal Methods defines an ordinal EvidenceLevel sequence ending in operational attestation. Replace that total order with claim-indexed evidence. A proof about a finite model, a replay of a recorded workload, a schema guarantee and a latency observation are complementary, not substitutable rungs. A release gate names the claim, artifacts, assumptions, bounds, checker and required evidence portfolio. [Formal methods and evidence] [Shadow verification and capsules]
Protocols: payload compatibility is weaker than behavioral compatibility. Admission, persistence, processing, cancellation and reconciliation need explicit meaning. The Surface documents already include behavioral versioning, while Graph Protocol and Work describe different completion and lifetime guarantees. These should be one shared vocabulary with qualified protocol-specific laws. [Surface contracts and interaction] [Graph protocol] [Durable work]
Execution truth: the Work document reports a 5 October conformance gate for scoped SQLite-backed claims and recovery, while still listing missing provider/device and durable-journal qualification. The FFI document reports working bridge experiments but says the general typed frame/Flow transport is unimplemented. The graph engine should reuse proven primitives, not equate these different statuses or create competing implementations of ownership and recovery. These are document-reported states; implementation qualification requires direct testing. [Durable work] [FFI / Switchboard]
Agent authority: Conductor supports inherited harness configuration and passthrough arguments. Those external tools may possess capabilities outside the graph command catalog. Governance claims must therefore bind effective harness and operating-system authority, or explicitly mark the run as partially ungoverned. A graph permission check is not an OS sandbox. [Conductor harness boundaries] [Formal methods and evidence]
12. Region releases and subgraph-level code push
The user-selected subgraph S is an editing unit. Compute a conservative compatibility closure C containing S under the selected module/target rules: include entities that must change together because a crossing contract changes, shared state needs coordinated migration, a continuation cannot cross versions, or compilation has erased an independently replaceable boundary. Refine toward a minimal unit only where the declared rules support it. Do not include all transitive dependencies indiscriminately; stable compatible dependencies can remain pinned imports.
The boundary of C includes every crossing incidence, not only ordinary directed edges. Each exported/imported port has a schema, protocol, role, ownership and effect contract. A multiparty hyperedge can cross the cut only with a qualified boundary mapping; slicing a session in half without its relation identity is invalid.
Semantic update granularity is not physical download granularity. Inlining, shared libraries or a JS bundle may require a larger artifact even for a one-node semantic change. Chunking/content addressing can avoid retransmitting unchanged artifacts; that optimization must not imply independent activation of coupled regions.
Package an immutable RegionRelease: selected and closed regions, base revision, canonical definition digest, per-target artifact digests, boundary descriptor, dependency vector, host requirements, state schema/migrator, activation policy, rollout policy and evidence references. A signature authenticates bytes and publisher. It does not establish correctness, grant additional capabilities or make an update compliant with distribution rules.
The server commits desired release intent and receipts. Hosts download and verify separately, stage the complete candidate, check runtime/policy compatibility, prepare state and then activate at a safe point. Distribution, eligibility, local activation and cross-host rollout are separate operations. A release only becomes observed-active after the target reports it.
Admission and activation
Admit a release only if its signature/provenance is trusted, host descriptor satisfies required capabilities and ABI profiles, pinned dependencies are present/compatible, exported contracts remain valid, required grants are currently available, state migration is acceptable, evidence is fresh and the channel/distribution policy allows the change. Fail closed for unknown required semantics.
Start with exact qualified compatibility fingerprints where possible, then add explicit equivalence profiles. Do not identify a native host merely as Android or iOS. It has installed service/FFI descriptors, renderer vocabulary, bytecode/VM version, memory rules and a set of updateable regions. Manifest requirements are not capabilities minted by the downloaded release.
Use signed manifests, trusted publisher scope, key-rotation strategy, bounded decompression/decoding and verification before execution. Keep a known-good embedded or cached release and durable activation receipts. An anti-rollback policy may forbid an older vulnerable artifact: intentional rollback must be an explicitly authorized newer release record, not arbitrary generation reversal.
Pin new invocation trees to one activation image. Existing calls and sessions retain their previous compatible generation. Shared writers require ownership fencing or quiescence; migrating state while the old owner continues writing is not a valid cutover. Never free native code or buffers while callbacks/resources still reference their generation.
Across devices and services, use a release vector with compatible mixed versions. Additive protocol evolution and expand/contract data migration are common strategies; some changes require draining old sessions or a coordinated maintenance window. Graph commit atomicity cannot force disconnected phones to activate simultaneously.
Runtime update classes
Expo provides the useful separation between the native binary and compatible update content. Runtime versions/fingerprints gate compatibility, signing verifies published updates, and staged rollout limits exposure. These mechanisms are precedents or reusable delivery components for suitable RN deployments—not evidence that Expo supplies Reaktor region-level activation. Expo runtime versions and updates Expo end-to-end update signing Expo update rollouts
For an installed RN host, update JS/assets or a graph program only when supported by its loader and existing native capabilities. New native modules, entitlements or incompatible native ABI requirements need a new app binary. Hot module replacement in development is a separate feature from production-safe update delivery.
For a compiled Kotlin/Native or Compose host, arbitrary new Kotlin machine code is not an assumed OTA feature. Options are data/configuration, a deliberately installed and qualified graph interpreter, supported JS/Wasm execution where available, or a conventional signed binary release. JVM and desktop hosts may use qualified loaders or processes, but class/state/resource compatibility still requires explicit handling.
For browser and server/Worker targets, publish immutable modules or artifacts and switch references according to host rules. A web refresh, a fresh Worker deployment and a live replacement inside one process have different continuity guarantees. Database schema changes and external work remain migration/reconciliation steps, not code swapping.
Technical executability and store permission are separate. Apple 2.5.2 restricts downloaded code changing functionality; 4.7 permits particular software categories under additional conditions. Google Play restricts externally downloaded dex/JAR/native executable code and specifies a qualified VM/interpreter exception. Neither an interpreted graph nor FlexBuffers is a compliance loophole. Obtain platform review for the concrete distribution model; platform compliance requires separate review. Apple App Review Guidelines, 2.5.2 and 4.7 Google Play Device and Network Abuse policy
Shadow should answer a named counterfactual question
What changes when this exact candidate runs under this exact approved workload?
Law / model / proof obligation: Evidence = f(base, candidate, artifacts, state cut, workload, policy, runner, fault schedule, coverage).
Reaktor design decision
Use isolated state, qualified nondeterminism control and explicit execution cuts. Compare expected behavior and invariants; record why evidence is applicable to this candidate rather than to a nearby commit.
What this does not establish
Opaque effects and live dependencies limit determinism. Recorded model outputs test orchestration, not the quality of today’s model. CDC plus recorded events must not apply the same mutation twice.
Falsifiable acceptance test. Change one artifact after the run. Evidence becomes stale; changing the acceptance policy needs independently authorized review.
Theory, precedent and Reaktor context: Shadow foundations Capture and replay Shadow verification and capsules Shadow workspaces FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)
A claim chooses its evidence—not the other way around
The docs’ EvidenceLevel scale should become a typed requirement over evidence kinds and scope.
Law / model / proof obligation: Claim = subject + proposition + profile + assumptions + bounds; evidence binds artifacts, method, coverage and verifier.
Reaktor design decision
A promotion policy can require several complementary kinds of evidence. Operational observation informs risk but cannot replace a universal theorem; a theorem over an abstraction cannot establish actual runtime latency.
What this does not establish
There can be a partial order for comparable claims, but no universal total order placing production attestation above mechanical proof. Avoid percentages that combine incomparable claims.
Falsifiable acceptance test. Ask whether a production trace proves that all future unauthorized writes are impossible. Reject that inference while retaining the trace’s actual observational value.
Theory, precedent and Reaktor context: Formal methods and evidence Shadow verification and capsules Lamport — A high-level view of TLA+ FoundationDB — A Distributed Unbundled Transactional Key Value Store (SIGMOD 2021)
Compatibility-closed region updates
Do not confuse a selection rectangle with a safe unit of runtime replacement.
Vector diagram · click a marked item to inspect
Reaktor design decision
Compute a compatibility closure under declared rules, preserve boundary roles and pin compatible dependencies. Keep physical artifact packaging separate from semantic edit scope.
Boundary / caveat
Inlining, native ABI changes, shared writers and persisted continuations may force a wider artifact, host rebuild, drain or explicit migration.
Qualification test. Change only a pure ranker, then change its shared schema. The second candidate must widen its update obligations and invalidate relevant prior evidence.
Official context and precedents: Expo runtime versions and updates Reaktor Visual Language / Blueprints
Region release and activation
A signed bundle identifies a proposed update. Only a compatible, authorized host may activate it.
Vector diagram · click a marked item to inspect
Reaktor design decision
Reuse the graph commit/receipt mechanism for desired release intent. Prepare immutable host images, pin old calls, stage state and publish one activation root per owned domain.
Boundary / caveat
A signature proves integrity/publisher under its trust chain, not correctness, permission or state compatibility. No global instantaneous mobile/server cutover is promised.
Qualification test. Inject a stale-evidence condition before promotion, a lost activation reply, and an in-flight old callback. Reject, recover by receipt, and preserve old resource lifetimes respectively.
Official context and precedents: Expo runtime versions and updates Expo end-to-end update signing Expo update rollouts Reaktor FFI / Switchboard
Runtime-specific update classes
Avoid a universal promise of live code replacement across every Reaktor runtime.
Vector diagram · click a marked item to inspect
Reaktor design decision
Describe the installed host precisely and compile each change to an eligible delivery class. Keep metadata updates, interpreted/script updates and native binary changes distinct.
Boundary / caveat
Store rules and host limitations remain independent gates. Expo runtime compatibility is a useful precedent, not automatic region hot-swap support.
Qualification test. A downloaded program requiring an absent native camera export must be rejected before execution, even if its signature and graph types are valid.
Official context and precedents: Expo runtime versions and updates How EAS Update works Apple App Review Guidelines, 2.5.2 and 4.7 Google Play Device and Network Abuse policy