Advanced execution — architecture and evidence review

[zenithruneblade]

Purpose and boundary

Track the advanced integration of concurrent Intents, constrained local resources, durable execution, remote labor, privacy, payments, and recovery.

This issue owns a finite architecture-and-evidence review and its decomposition into bounded work. It links existing delivery issues without expanding their acceptance criteria or making advanced work a prerequisite for the first local conversation or multimodal receipt.

“Advanced execution” names a finite architecture-and-evidence review. It introduces no runtime component, umbrella implementation, or additional authority.

The sources of truth remain separate:

• ADRs own accepted architecture.
• State of Work owns delivery interpretation.
• Tracked source, focused tests, lockfiles, and maintained receipts establish executable evidence.
• This issue records coverage, dependencies, review findings, and follow-up scope.
• #52 remains the project-wide roadmap and contribution route.

Accepted changes belong in their existing canonical owners. A discussion, diagram, closed issue, or passing simulation does not independently establish architecture or delivered behavior.

Current evidence boundary

The verified envelope remains local, loopback-oriented, single-user, and one control process.

State records available subsets for deployment-plan compilation, the narrow Animator/Dispatcher path, and Topology-A Run execution. Safe runtime transitions, persistence, consent recovery, and delegated execution have explicit partial boundaries. Host/model integration still needs named operator receipts.

Resource-aware scheduling, general service capabilities, execution-road planning, verified Privacy Cuts and egress, native Oculus, Shadow, A2A, Tether, Toll, and Legion remain designed within their respective boundaries. Portal grant issuance remains quarantined. The delegated reference adapter performs no external effect. Current Graph execution is serial; hardware waits are live and do not generally survive process loss.

Use State’s exact labels and limits when recording a review. Missing evidence is a review gap; an unknown physical observation is runtime uncertainty. Neither is a replacement delivery classification.

Advanced scenario

Use one versioned synthetic scenario, with independently executable stages as their dependencies become available.

The initial host profile is Linux with systemd, cgroup v2, and rootless Podman/Quadlet. Illustrative inputs are one 24 GiB GPU, an already-WARM coder profile with an 18 GiB observation and live leases, a conflicting vision profile with a 20 GiB observation, and an embedder profile with a 5 GiB observation and declared coexistence with coder.

Those numbers are fixture inputs, not hardware qualification or proof of fit. Each measured profile must include workload conditions, observation age, active and transition-peak demand, required headroom, relevant host resources, and device identity. A declared capability must also have an admitted executable interface; family metadata alone is insufficient.

Exercise the following sequence:

1. Concurrent demand. Admit independent Intents for foreground coding, deadline-windowed visual work, and bounded background work. Preserve each Run’s owner, exact workflow revision, authority, budgets, and deadlines. Later include Graph — nested subgraphs & bounded parallel execution #61’s nested branches without treating independent Runs and parallel branches as the same topology.
2. Contention and transition. Keep existing coder leases live while vision waits. Determine whether embedding is actually admissible. Close affected admission before drain; replan after preceding transitions and refuse stale or insufficient evidence.
3. Future-demand weighting. Compare current-demand-only policy with a proposed bounded prediction signal for later Graph requirements. Pin its source, horizon, confidence, age, units, normalization, tie-breaks, and missing-data behavior. Record false predictions, starvation, unnecessary switches, deadline misses, and transition cost. Prediction is a proposed policy input, never an admitted future demand, lease, reservation, or effect permission.
4. Distinct execution roads. For an explicitly declared station, evaluate local work, one Portal operation, one contained coding AgentJob, and one sovereign A2A task according to their different labor contracts. A delegated runtime’s child provider calls are separate disclosure boundaries. A peer chooses its own private decomposition.
5. Consumer-specific disclosure. Use synthetic records carrying representative classifications. Create independent minimum projections and required Privacy Cuts for the provider, peer, and delegated runtime. Reject a cheaper route when its privacy, utility, authority, custody, or containment requirements fail.
6. Durable interruption. Inject failure before submission, after possible acceptance but before acknowledgement, after checkpoint but before park, and after terminal commit but before cleanup. Recover the exact applicable delivery, attempt, task, or job identity. Demonstrate explicit refusal where current recovery is unsupported.
7. Network and economic interruption. Drop an admitted Tether route and revoke its peer without public fallback. Introduce a simulated x402 challenge, changed quote, expired authorization, and ambiguous settlement. Distinguish accounting, settlement, and delivered work.
8. Shadow and observation. Run a bounded Shadow comparison only under admitted service/resource policy. Retain reviewed alternatives or an honest non-decision, including cleanup residue. Correlate the competing work while preserving producer ordering, gaps, observation freshness, and ledger authority.
9. Eventual owned-node boundary. Document how the same requirements would change under Legion: expiring advertisements, node-local admission and refusal, reservations, epochs, partitions, and stale results. This stage is a boundary review, not a fleet implementation commitment.

Related execution roads and enabling layers

The master scenario composes several declared execution roads, but it must not flatten them into interchangeable provider buckets. For each station, Spellweaver seals one admitted road decision before submission:

Intent / pinned Scroll
  -> Spellweaver road decision
     -> local capability -> Dispatcher
        -> exact WARM grant + lease -> bounded call
        -> readiness transition required -> Graph parks handle-free
           -> Orchestrator converges managed state -> fresh Dispatcher request
     -> Portal provider operation
     -> contained CLI coding AgentJob
     -> sovereign A2A peer task

Operationally, Portal, delegated coding and A2A expand the set of roads that an eligible station may use. They retain different identities, authority, custody, cancellation, reconciliation and terminal-adoption contracts. Local failure does not silently admit a remote road, and changing road is not an implementation detail.

Related concern	Existing owner	What it adds to orchestration	What it does not add
Local managed capability	#7, #6, ADR 22, ADR 23	Exact WARM grant, lease and managed readiness transition on the local host	Semantic provider choice or permission to bypass systemd ownership
Portal	#55, ADR 20, ADR 22	One explicitly admitted remote provider operation with an exact binding	Automatic fallback when local execution is cold or failed
Contained CLI coding agents	#28, ADR 14, delegated agents	A durable AgentJob road for adapters around Codex-, Claude- or OpenCode-shaped runtimes, with a scoped workspace and quarantined return	Ambient credentials, live RunContext, automatic merge/promotion or authority for the runtime's child provider calls
A2A / Intercom	#19, ADR 26	A sovereign peer task whose remote owner chooses its private workflow, models and tools	A generic provider pool, shared database, fleet membership or imported foreign private state
Weaver Privacy Cut and egress	#25, #38, ADR 21, ADR 09, anonymization	Consumer- and purpose-specific transformation, disclosure admission and exact-byte lineage before an external crossing	A universally reusable sanitized payload or proof that the selected road is trusted
Tether / VPN	#20, ADR 39	Explicit private reachability for an admitted peer or endpoint	Application role, task authority, object access, anonymity or permission to fall back to a public route

A contained CLI runtime and any provider it invokes are separate consumers. Each child call therefore needs its own declared provider binding, disclosure decision and applicable Cut; admitting the outer AgentJob does not transitively admit arbitrary network use.

The VPN relationship is similarly narrow: it can make an A2A peer reachable and thereby make that declared road operationally available, but it cannot make the peer eligible, trusted or authorized. The road decision, Ward checks, Privacy Cut, egress decision and road-specific effect record remain necessary.

A2A over optional Tether

For a station whose pinned policy admits a private A2A road, review this exact chain:

Spellweaver selects the declared A2A road
  -> Ward admits peer, task and current authority
  -> Context produces the peer/purpose-specific Privacy Cut
  -> egress admits the exact final bytes
  -> optional Tether route is already admitted and healthy
  -> A2A owner persists task identity and outbound intent before submission
  -> Graph parks only after durable continuation, holding no local capability lease
  -> authenticated terminal result is quarantined, checked and adopted once

If Tether is required but absent before submission, that road is ineligible and the declared policy may refuse or select another already admitted road. If the tunnel drops after possible submission, no public fallback is allowed: retain the same A2A task/effect identity, expose the uncertainty and reconcile. Tunnel restoration does not mint peer authority or permit a changed payload to reuse the old identity. #19 owns task semantics and #20 owns private reachability; neither becomes a generic provider adapter.

Worker progress, configurable fallback and Graph growth

The composed scenario must prove bounded progress, not claim that arbitrary future workflows are mathematically deadlock-free:

• a Run parks only after its durable wait and continuation commit; it releases run-scoped context and any local grant or lease before waiting;
• Ghoul and service-attempt claims are fenced, duplicate/stale delivery is rejected, heartbeats and shutdown are bounded, and every started branch reaches a terminal, parked or explicitly unknown owner state;
• no waiter retains a resource needed by the work it awaits; Orchestrator closes admission before affected-set drain, then Graph redispatches from fresh evidence after convergence;
• configuration pins policy for new admissions. Dispatch — configurable ranking & bounded fallback #17 may rank or fall back only among declared semantically compatible candidates under a total budget. Cold readiness is a wait/converge/redispatch cycle, not fallback;
• pre-effect refusal may admit a declared alternative. Possible submitted effects reconcile under their road-specific identity; provider, peer, payload, workspace or road changes require a new Spellweaver road decision and applicable effect identity.

Graph extension remains additive. #29 admits exact owner-qualified Spell contracts, immutable Scrolls and Resolution Locks; #61 adds bounded branch identities, joins and cancellation. A router may fold only alternatives declared by the pinned Scroll into one typed execution projection using exact predicates and capability evidence. It cannot invent an edge, import code from YAML/TOML, or rewrite a live Run. YAML is at most a typed authoring projection compiled to canonical JSON; TOML selects already registered exact identities and bounded policy.

Altar review route

The operator review should remain distributed across the existing Altar instruments rather than creating an Orchestration Master screen:

Instrument	Review question for this scenario
Bridge / Circle (#11)	Which Intent opened the canonical Run, which Pattern revision was pinned, and what status/consent/cancellation does the Run ledger report?
Loom (#14)	Which exact Scroll, stations, branches, capability demands and execution-road alternatives were declared?
Orb (#13 / #36)	Which stations and attempts actually occurred; which road decision, grant, wait, transition, AgentJob, A2A task or external effect was retained; and where are the evidence gaps?
Nexus (#12)	What is currently declared/observed about local capability readiness, and what exact managed transition was previewed, requested or settled?
Atlas (#15)	Which continuing concern or decision cites the exact Bridge conversation or Orb evidence, without acquiring runtime authority?

The review journey is Bridge → Orb, with Orb → Loom for declared score and Orb → Nexus for a correlated physical transition; Atlas retains explicit references and decisions. #9 owns delivery and cross-screen navigation. Missing projections remain visible gaps and do not authorize a retry or infer an event.

Authority that the scenario must preserve

Owner	Responsibility
Composition / domain	Meaning of requested work, result acceptance, records, and effects
Spellweaver	Exact score, logical coordination, temporal admission, and declared execution-road policy
Dispatcher	Match current typed demand and admit an exact eligible WARM capability with a lease
Orchestrator	Admit and serialize managed local readiness transitions; close admission, drain, revalidate, converge, compensate, or contain
Bind / Scribe / actuator / systemd	Compile and attest owned topology, then execute and classify the bounded physical transaction
Workers / Graph / Phylactery	Exact delivery ownership, supported checkpoints, durable waits, settlement, and recovery
Ward / HitL / Security / Context	Current authority, exact consent, byte-time egress, lineage, and consumer-specific transformation
Road-specific effect owner	Submission, external identity, cancellation, reconciliation, and terminal evidence
Oculus / Orb	Bounded observation and explanation, without replacing authoritative records

A waiting hardware Run holds no capability lease. Successful convergence requires fresh dispatch.

Priority does not interrupt a submitted physical transaction. A “spare capacity” label does not establish safe preemption; scarce-resource background work needs a proved yield/containment boundary or an explicitly admitted quiet window.

Generated conflict relationships, Coven grouping, and measured capacity remain different facts. Direct systemd or Podman control cannot become a second application lifecycle path.

Concern and evidence matrix

Each row needs a review result, an exact evidence route, explicit limits, and a bounded disposition for remaining work. Existing issues retain their own scope.

Concern	Canonical owner	Existing work	Evidence required for the advanced scenario
Declared topology and host lifecycle	ADR 08	#3, #18	Owned generation and loaded topology agree; binding, readiness, shutdown, and restart receipts identify their host and limits
Exact dispatch and leases	ADR 20, ADR 22	#7, #42	Eligibility before ranking; fresh issue-time observation; exact-selection refusal; lease/provider cleanup; unsupported interfaces remain refused
Readiness transitions	ADR 23	#6, #50	Affected-set drain; observation/admission races; pre-effect refusal; post-effect settlement; exact restoration or containment
Measured resource policy	ADR 23	#16	Headroom and transition peaks; overlapping versus disjoint devices; priority/FIFO behavior; named physical measurements separated from synthetic stress fixtures
Selection and future-demand weighting	ADR 22, ADR 23, ADR 28	#17, #16; follow-up below	Versioned ownership of each signal; hard constraints preserved; prediction disabled/stale/wrong; bounded fallback and switch cost explained
Temporal admission and service classes	ADR 28, ADR 14	#29 is an adjacent first slice; follow-up below	Durable trigger identity; eligibility and misses; overlap; bounded catch-up; foreground/deadline fairness; proved background yield
Graph and workflow continuity	ADR 24, ADR 28	#8, #29, #61	Pinned score/bindings; isolated branch state; join and cancellation settlement; checkpoint compatibility; separate Run and branch ownership
Durable delivery, effects, and restart	ADR 06, ADR 14, ADR 24	#47, #22, #26	Real PostgreSQL transaction and restart evidence; exact wait owner; crash windows; lost acknowledgements; no blind replay; durable resource handoff separately scoped
Artifact and caller authority	ADR 06, ADR 09, ADR 38	#23, #24, #37	Authorized byte custody, quarantine, revocation, stale references, and effect-time checks
Execution-road composition	ADR 28	#29, #55, #28, #19; follow-up below	Decision committed before submission; correct road ledger; no hidden route change; terminal adoption preserves application ownership
Portal and delegated coding	ADR 20, ADR 22, ADR 14	#55, #28	Exact provider binding; contained runtime and scoped workspace; credentials outside the child; each child call admitted separately; process-tree containment and ambiguous-start evidence
Sovereign A2A	ADR 26	#19	Pinned adapter/envelope; peer authority; durable outbound identity; authenticated terminal adoption; duplicate/revoked/expired/unknown outcomes
Privacy Cuts and transmission	ADR 21, ADR 09	#25, #38	Consumer/purpose-specific projection; complete transformation chain; independent disclosure and utility checks; exact final bytes; refusal on missing lineage or stale evidence
Private reachability and ingress	ADR 39, ADR 40	#20, #57	Exact routes and separate application authority; revocation survives restart; tunnel failure cannot open a public alternative
Shadow	ADR 31	#41, #33	Pinned base and strategy; bounded independent branches and review; resource limits; explicit non-decision; cleanup receipt; no self-promotion
Toll and x402	ADR 41	#32	Separate quote, reservation, authorization, submission, settlement, delivery, and reconciliation; simulated duplicate/ambiguous charge cases; no payment-derived authority
Cross-Run explanation	ADR 29	#36; follow-up below	Run/delivery/station/grant/transition/job correlation; producer order and gaps; stale metrics; decision explanations; redaction before serialization
Owned-node extension	ADR 42, ADR 26	#52’s later-direction pointer	Local versus remote reservation and fence boundaries; node refusal; partition/restore/version-skew cases; no shared database or raw remote host authority

Canonical ADRs are listed in the Covenant index. Operational routes:

• Execution roads
• Scheduling and service classes
• Delegated agents
• Anonymization, taint, and egress

Effect and retry coverage

The review must distinguish these cases:

• Proved pre-effect failure: a declared retry or alternative may be considered under fresh admission.
• Possible submitted effect: retain the same effect identity and reconcile. Timeout, cancellation request, worker death, or missing observation does not prove containment.
• Permitted exact transport redelivery: retain sealed bytes, target, road-owned identity, road decision, and Cut/namespace; require adapter-proved same-key/same-payload replay or evidence of no prior effect, plus a fresh EgressDecision and remaining disclosure allowance.
• Changed semantic attempt: changed payload, provider, peer, model, workspace, policy, or custody route requires a new road decision and applicable effect identity; transformation requires a fresh consumer-specific Cut.
• Terminal or unknown result: apply the road’s own terminal/adoption law. LOST, INDETERMINATE, and cancellation states must not be flattened into a generic retriable failure.
• Observation loss: show the gap while preserving the authoritative ledger outcome.

Host transitions, service attempts, AgentJobs, A2A tasks, and Toll settlements have different records and recovery rules. This master does not replace them with a universal state machine.

What counts as covered

For each matrix row, record:

1. The exact scenario, failure injection, expected result, and responsible decision/effect owner.
2. The governing invariant and canonical revision inspected.
3. The identities and durable state required across the tested boundary.
4. The no-effect/effect crossing, cancellation semantics, reconciliation path, and containment limit.
5. Configurable policy ownership, scope, units, defaults, bounds, revision pinning, and missing/stale-input behavior.
6. Source and focused tests for implemented behavior; a maintained receipt for any claimed integrated behavior.
7. Evidence class and limitations: deterministic fixture, database/process restart, inert private-systemd, named host/model, or independent endpoint.
8. The matching State entry and its exact delivery boundary.
9. A disposition: covered within that boundary, accepted gap assigned to bounded work, explicitly deferred, or not applicable with rationale.

Receipts identify source/configuration/profile revisions, commands, relevant runtime versions, expected and observed outcomes, and cleanup. Deterministic control tests do not establish deterministic model answers or predictable resource availability.

Published evidence uses synthetic material and allowlisted structural fields. Prompts, credentials, private errors, raw source identifiers, and pseudonym maps do not enter the tracker or ordinary telemetry.

Bounded follow-up gaps

Confirm the smallest useful slice before opening each follow-up. Prefer an existing issue when its accepted scope already covers the work.

Proposed follow-up	Finite first result	Why existing scope is insufficient
Spellweaver — one durable deadline-windowed Occurrence	One pinned schedule, deduplicated firing, eligibility/miss/overlap behavior, and restart receipt through ordinary Run admission	#29 explicitly defers schedules; queue names and scalar priority do not supply the temporal contract
Orchestration — durable local reservation and hardware-wait recovery	One managed service attempt with a durable reservation/fence, explicit park/restart ownership, and release only after proved containment	#16 and #22 defer durable reservations; current live hardware waits and process-local leases cannot prove this
Workflow — exact execution-road decisions and safe road changes	One native placement selecting between two declared roads, with persisted decision/effect linkage and pre-submit versus ambiguous-post-submit tests	#55, #28, and #19 each prove one road; #29’s first Scroll does not implement the cross-road policy
Runtime policy — bounded future-demand signal	One versioned non-authorizing prediction contract and controlled comparisons for correct, stale, absent, and wrong predictions	#16/#17 cover measured resources and local ranking, but do not yet define this cross-owner signal
Oculus — explain contention across two Runs	One bounded correlated view of competing Runs, resource observations, rejected choices, and transition outcomes	#36 deliberately proves one Run and defers multi-Run queries/resource snapshots

Consumer-specific Cut composition, Shadow resource behavior, and Toll integration should first use the relevant child issues’ receipts. Create additional work only for a demonstrated gap.

Legion remains an explicit deferred boundary under #52 and ADR 42 until local admission, durable delegation, identity, and fencing evidence justify a concrete first node slice.

Non-goals

• Implement every execution road or close every linked issue through this tracker.
• Change the completion order of first local conversation, multimodal integration, and later resource/ranking policy.
• Create another scheduler, lifecycle controller, effect ledger, architecture source, or delivery ledger.
• Treat declared coexistence, synthetic GPU arithmetic, broker concurrency, or prediction as resource admission.
• Introduce unsafe preemption, silent remote fallback, live Graph rewriting, or automatic replay after an ambiguous effect.
• Expose the current loopback application through a tunnel or generic proxy.
• Move real money, enable production x402, or infer spending authority from a challenge.
• Deliver fleet placement, distributed Graph execution, shared Phylactery storage, or autonomous repair.
• Treat a technical return, simulation result, score, or trace as authority to merge, publish, deploy, or promote.

Completion condition

Close this tracking review when:

• The versioned synthetic scenario and matrix have been reviewed against their canonical owners.
• Existing executable evidence and its limits are linked at a recorded source revision.
• Every accepted gap has one bounded issue or an explicit, reasoned deferral.
• Dependencies distinguish completion blockers, coordination links, and actual sub-issues; existing delivery slices have not acquired reciprocal advanced blockers.
• Contradictions discovered in owning documentation are repaired or linked to explicit unresolved work.
• The final review records which scenarios are executable, which remain designed, and what evidence is still required.
• Roadmap & contribution opportunities #52 has a concise route to this advanced tracker.

Closure means this review and decomposition are complete. It does not mean the advanced integrated runtime has shipped. That claim requires the relevant implementation issues, composed acceptance receipts, and an updated State of Work.