design: specify dispatcher capture retirement and profile integration.

[jm9e]

Current owner packet — 2026-09-26

The detailed lifetime observations retained below remain the acceptance source. Current implementation ownership is bitruntime #13, not a new nightseam release. Runtime v0.2.0 already includes the public invocation lifecycle; this issue remains open for the observation-by-observation independent integration/disposition, not another primitive rename.

Wire is now addressless, full WireTree supplies structure, and the historical addressed vocabulary in the older record refers to AddressedWire at today's boundary. Naming alone does not discharge capture/body/control authority.

Remaining contract and signoff work

• Map every original acceptance observation to exact released evidence or a concrete missing owner row; preserve the distinction between bitwire test-only and actual runtime/generated/physical/live/tunnel evidence.
• Settle any remaining public authority/participation ambiguity through #55, with two independent integrations and an opaque wrapper. No private-context-only exception.
• Require explicit body ownership/completion, both stale-control races, cancellation latching, bounded depth/fan-out, shutdown and separate live-value lifetime; do not replace these with retained-reply fixtures.
• Integrations are owned by runtime #13, tunnels #11, live #12 and bitlink #1. Each missing row needs a linked release/evidence disposition before signoff.
• Publish final current contract/migration notes with immutable native/profile identities and reciprocal owner links. Do not revise historical tags.

Carrier closing/publication guarantees are #54. Raw relay attachment lifetime is separately bitwire-svc #13; the relay does not acquire application invocation admission policy. Generic service design consumes only the applicable public capability/lifetime requirements.

The bounded runtime #1/bitsystem3 #7 milestone can complete with its stated existing-profile coverage; this issue does not silently widen that gate. Coordinator: #47. New code/conformance paths retain component-first two-letter language layout.

Historical issue record (preserved; current execution instructions are above)

Deixis service coordination — 2026-09-25

Related API redesign: #42; service coordinator: https://github.com/Bitspark/deixis-svc/issues/1. Wire A0 is the addressless conveyance primitive and Deixis supplies addressed A1. The API is open to change; the old primitive-preservation wording below is not a fixed premise against that operator direction.

The independently stated lifetime observations remain requirements wherever an endpoint/profile claims invocation-aware routing. Assign capture, cancellation, body completion and retirement to their actual owners in the new layering. They do not require the raw A0 relay to inspect application operations or execute application-level admission policy. Relay resource/attachment lifetime remains its own concern in https://github.com/Bitspark/bitwire-svc/issues/9.

Neither structural Deixis laws nor message relay acceptance alone prove invocation lifecycle conformance. Carry the applicable cases and exact evidence forward explicitly.

---

Bitwire disposition and executable baseline, 2026-09-22

PR28 is merged at 0f30b515694cb3005403229be0f4e4158baf41b9. ADR0004 resolves the two findings from PR26: callable return Wire access has its own profile-defined path space, and Nightseam's recorded pre-1.0 release-based compatibility disposition is accepted for the exact v0.6.0 baseline, without claiming arbitrary mixed-release compatibility.

The required conformance gate passed: six Bitwire composition observation groups in Go and TypeScript over local pairs and both WebSocket role directions; five independently specified lifecycle cases in each language; separate pinned upstream independent-endpoint, opaque-wrapper, serial, execution-budget and lifecycle tests, including Go races. The historical 0.1 baseline also remains green. All required PR checks passed before squash merge.

This issue remains open. The coverage and remaining-acceptance table keeps generated/live/context acceptance, execution-owner authority, shutdown and asynchronous control drain explicit. The original criteria below are not marked complete merely by this scoped baseline. A downstream domain attachment demonstration is a separate consumer obligation. Published Wire/Endpoint declarations remain unchanged.

Operator requirement: finish the long-term public lifecycle interface now

The operator explicitly requires the correct, conceptually sound long-term interface now. Do not declare this work complete with a private-context-only migration or defer the public integration as optional future work. The detailed requirements are recorded in ADR0003, landed in Bitwire PR21.

• Preserve the small generic Wire/Endpoint boundary unless a concrete obstruction demonstrates a needed extension. The invocation, not the registration or callback, owns immutable captured routing state per traversal.
• Deliver a public, explicit, profile-specific lifecycle API and state rules in Go and TypeScript. Construct invocation-aware dispatch with this facility or an equivalent public capability. Private storage is fine; private concrete-type recognition, endpoint unwrapping or an exported lookup that works only with a private native ledger is not sufficient.
• Include public participation by execution owners/generated binders to report actual body completion. Dispatcher authority to capture/observe must not silently grant authority to finish another owner's work or forge admitted/verified context.
• Distinguish queue admission, invocation admission, caller withdrawal, fixed outcome, body completion, admitted-control drain and retirement. Capture is race-safe and cancellation latched while nested captures are attached. Repeated traversal of the same dispatcher has distinct capture identity.
• Prove both identity-reuse races. An already queued control retains its invocation generation; a newly arriving indistinguishable old control cannot be solved by a private generation counter. State the enforceable nonreuse/scope/identity/barrier rule at the actual carrier boundary. A fresh local Return alone is insufficient if physical controls still have the same peer/request ID. Avoid unbounded tombstones.
• Bound admitted work AND total capture/control cost, including depth and shallow fan-out. Timeout does not release execution capacity while the body runs; RPC retirement does not release returned live values.
• Before freezing the lifecycle API, exercise two independently implemented same-profile endpoint integrations plus an opaque forwarding wrapper, through only public facilities and without a shared private ledger. Same frame vocabulary alone is not lifecycle participation. Unsupported endpoints have explicit refusal, but refusing every non-native implementation is not evidence of composability.
• Deliver the small compilable API/state packet and independent experiment before final migration signoff, then actual generated/local/physical/tunnel/live acceptance. Retained-reply fixtures and package publication do not close this concern.

Bitwire 0.2.0 is already public and immutable. That is not a design freeze at the expense of correctness. If evidence requires changing shared public declarations, coordinate a reviewed new version; do not keep a private exception merely to avoid a release, and do not rewrite the existing tag. Any changed physical identity semantics need an explicit compatibility/profile-version decision.

Question and current behavior

How does an invocation-aware dispatcher preserve the receiver captured by an admitted request through detach/rebind, then reclaim that capture within bounded memory, while preserving the exact return-capability identity?

This is a focused follow-up to #18 / #19 and Nightseam #439, filed at the operator's request. The released 0.2 contract from #19 already correctly states that callback return is not invocation completion and that terminal-state ownership belongs to explicit profile integration. This issue records the obstruction, the required integration boundary, and the evidence needed to discharge it. It does not claim a released Bitwire runtime defect or request a competing implementation.

Existing composition and obstruction

Wire supplies send-only access; Endpoint adds one owning receive attachment and closure. Shared sibling/nested receiving views can use one explicit dispatcher. Routing policy can move out of the primitive, but request lifetime cannot be inferred from routing alone:

1. A dispatcher delivers request R to receiver A. A returns immediately and finishes asynchronously.
2. A is detached and B is registered at the same path.
3. A response goes directly through R's original Return.Wire, bypassing the dispatcher. A later cancellation must still reach A, with the original return identity.

From the bare dispatcher interface, an execution where A has already replied and one where A remains active are indistinguishable. Dropping the capture too soon can lose or redirect cancellation; retaining every capture indefinitely leaks memory or exhausts a fixed capacity after enough sequential successful calls. A fixed timeout, callback return, a TypeScript Promise when callbacks may return void, or a weak map does not establish the required terminal lifetime. Wrapping the return capability to intercept replies violates the preservation requirement.

Nightseam's existing implementation obtains this evidence from its runtime, not from the callback:

• Local admission and captured registration: localWireCall retains the chosen registration; localReturn.Send observes the actual response. Retirement waits until completion and any already queued cancellation has drained. A receiver deadline may answer early while the executing body still occupies its budget.
• Physical peer dispatch and reply waiter: requestReceiver captures the receiver in a closure; an admitted incoming callWire continues waiting after cancellation until the actual reply.
• TypeScript registration: registerWire starts a void Promise.resolve() chain, so returning from its callback is explicitly earlier than handler completion.

Alternatives and recommendation

Retain the small 0.2 primitive and document the additional profile integration needed for invocation-aware routing. One shared dispatcher owns routing; the profile/runtime owns admission, captured invocation state, cancellation and terminal retirement. The runtime may store selected-route snapshots in private invocation state, but dispatchers and independent execution owners must participate through an explicit public lifecycle/capture capability. Private storage is an implementation choice, not an alternative to the public integration contract in ADR0003. This need not replace the original return object or add a peer/channel/queue per selected view.

The integration must define:

• Which boundary captures the route and makes its state available to later cancellation, including nested dispatchers and forwarding.
• The difference between caller withdrawal, an early deadline response, actual handler completion and final queued-control retirement.
• Capacity, retirement, shutdown and same-return/request-ID reuse; late controls must not delete or address a newer capture.
• Behavior for a custom return capability or third-party Endpoint that lacks the implementing runtime's private context. A silently weaker fallback must not claim full capture guarantees.
• Which guarantees belong to Bitwire's generic composition experiment and which require actual profile/runtime acceptance. Retained replies alone do not prove cancellation routing or bounded reclamation.

No new primitive is prescribed by this issue. If the documented profile seam cannot satisfy these observations, record that concrete obstruction before changing the shared declarations. Implementations remain in their owning repositories.

Acceptance observations

• Go and TypeScript: a void/early-returning receiver responds asynchronously; detach/rebind does not redirect its cancellation or change its return-capability identity.
• More sequential successful requests than the configured in-flight capacity reclaim capture state; genuinely unfinished requests remain bounded.
• A response racing an already queued cancellation and same-key reuse cannot deliver old controls to, or retire, the new invocation. Separately prove that a newly arriving old control cannot address a newer invocation: document enforceable identity scope/nonreuse or a real distinguisher/barrier at each carrier boundary, bounded enforcement, exhaustion and any profile-version change.
• Receiver timeout may settle the caller early, but an ignoring application body retains its execution budget until completion.
• Identity-deferred delivery, sibling and nested receiving views, mounts and two-connection forwarding preserve the same ownership and capture behavior.
• Two independently implemented same-profile endpoint integrations and an opaque forwarding wrapper exercise the public lifecycle facility without shared private ledgers, private concrete-type recognition or endpoint unwrapping. Execution owners report authoritative body completion through the public contract. Unsupported participation is explicit.
• Nested and repeated traversals preserve distinct captures, cancellation is latched during capture installation, and total retained capture/control cost (including shallow fan-out) is bounded. Shutdown does not prematurely release a still-running body's budget; invocation retirement does not release returned live values.
• The final 0.2 contract/migration notes identify the profile integration requirement, and the handover links actual Nightseam acceptance separately from Bitwire's test-only composition evidence.

The normative limitation is already acknowledged in the released contract from #19. Keep that statement, settle the profile seam with the Nightseam owner, and close this concern only with the corresponding decision/evidence links or an explicit cross-repository disposition of the remaining implementation checks.

[jm9e]

Reviewed this issue before merging/tagging0.2.0. Its obstruction is valid: a bare router cannot infer asynchronous invocation retirement when replies bypass it. This does not require adding a primitive method; it requires an explicit runtime/profile lifecycle integration with honest supported behavior for unmanaged endpoints.

PR19 now incorporates the issue in ADR0002 and the normative contract. It explicitly requires distinctions between caller withdrawal, early deadline settlement, actual body completion and queued-control retirement; safe same-key reuse; bounded unfinished captures and reclamation over sequential completions. Endpoint alone does not supply a runtime lifecycle association. Invocation-aware routing must require the explicit integration or refuse unmanaged invocations rather than silently retarget them.

The reference Go/TypeScript experiment proves delayed replies after detach/view closure/route replacement, including same request ID with distinct original return identities. It deliberately does not claim cancellation routing or bounded retirement. Keep this issue open for the remaining actual profile/runtime evidence in Nightseam #439; contract publication must not mark that implementation acceptance complete.

[jm9e]

Operator requirement: finish the long-term public lifecycle interface now

The operator explicitly requires the correct, conceptually sound long-term interface now. Do not declare this work complete with a private-context-only migration or defer the public integration as optional future work. The detailed requirements are recorded in ADR0003, being landed through Bitwire PR21.

• Preserve the small generic Wire/Endpoint boundary unless a concrete obstruction demonstrates a needed extension. The invocation, not the registration or callback, owns immutable captured routing state per traversal.
• Deliver a public, explicit, profile-specific lifecycle API and state rules in Go and TypeScript. Construct invocation-aware dispatch with this facility or an equivalent public capability. Private storage is fine; private concrete-type recognition, endpoint unwrapping or an exported lookup that works only with a private native ledger is not sufficient.
• Include public participation by execution owners/generated binders to report actual body completion. Dispatcher authority to capture/observe must not silently grant authority to finish another owner's work or forge admitted/verified context.
• Distinguish queue admission, invocation admission, caller withdrawal, fixed outcome, body completion, admitted-control drain and retirement. Capture is race-safe and cancellation latched while nested captures are attached. Repeated traversal of the same dispatcher has distinct capture identity.
• Prove both identity-reuse races. An already queued control retains its invocation generation; a newly arriving indistinguishable old control cannot be solved by a private generation counter. State the enforceable nonreuse/scope/identity/barrier rule at the actual carrier boundary. A fresh local Return alone is insufficient if physical controls still have the same peer/request ID. Avoid unbounded tombstones.
• Bound admitted work AND total capture/control cost, including depth and shallow fan-out. Timeout does not release execution capacity while the body runs; RPC retirement does not release returned live values.
• Before freezing the lifecycle API, exercise two independently implemented same-profile endpoint integrations plus an opaque forwarding wrapper, through only public facilities and without a shared private ledger. Same frame vocabulary alone is not lifecycle participation. Unsupported endpoints have explicit refusal, but refusing every non-native implementation is not evidence of composability.
• Deliver the small compilable API/state packet and independent experiment before final migration signoff, then actual generated/local/physical/tunnel/live acceptance. Retained-reply fixtures and package publication do not close this concern.

Bitwire 0.2.0 is already public and immutable. That is not a design freeze at the expense of correctness. If evidence requires changing shared public declarations, coordinate a reviewed new version; do not keep a private exception merely to avoid a release, and do not rewrite the existing tag. Any changed physical identity semantics need an explicit compatibility/profile-version decision.

[jm9e]

Minimal common surface: additional API is not yet justified

The operator has challenged why invocation composition should require a second commonly agreed interface, specifically the proposed public Reply(request, response) operation. This is a design acceptance question, not authorization to treat that operation as already necessary.

The obstruction above establishes that a bare router cannot infer invocation lifetime from request delivery when responses bypass it. It does not establish that another native interface or a dedicated Reply operation is required. The requirement is explicit, interoperable lifetime information; its representation still needs justification.

In particular, the current bridge proposal creates a second full invocation owner B, makes B retirement depend on a separately observed outcome, and then adds Reply because an unchanged return capability sends the response directly to A. Review whether this is an avoidable consequence of the chosen ownership model. Compare B as a local captured-traversal/execution scope under the original invocation authority, retaining and releasing only its actual delivery/body/control obligations. Independent implementations using an opaque public capability are not the same as implementations coupled through a shared private ledger.

Before expanding the common boundary, compare participation through the existing Wire and an explicit lifecycle/control protocol with a separate required native interface. Protocol semantics are still shared agreement and must be documented honestly; merely calling a new API profile-specific does not remove its integration cost.

The existing correctness observations remain required. A new Reply method or second interface must be justified against the simpler alternatives, rather than assumed by the acceptance experiment. Bitwire 0.2.0 Wire/Endpoint signatures have not changed again.

[jm9e]

Bitwire review of the lifecycle evidence: open, with two contract findings

Reviewing Nightseam PR444
against this issue's acceptance observations. This is a review in progress,
not signoff: the review is against the PR's own account of its evidence, not a
reading of its implementation, and its checks are not green. Nothing here claims
a defect in the released 0.2.0 declarations.

What the chosen form settles

The 11:09Z challenge is answered. The frozen form is a protocol over the existing
Wire — an admitted invocation presented as its return capability, lifecycle
carried on that capability's paths — rather than a second commonly agreed native
interface or a public Reply operation. Nothing is added to Bitwire, so no
new Bitwire package release is indicated by this work, and the
0003
contingency for a properly versioned change to shared declarations does not fire.
That is the outcome this repository asked for: the lifecycle facility is a
profile API, not another method on Wire.

PR444 reports stage (c) complete — the public lifecycle API replacing the private
ledger, two independent endpoint integrations, the opaque forwarding wrapper,
both identity-reuse races, cancellation latched during capture installation,
retirement waiting on body and control drain, bounded captures and bodies as
totals, 32 sequential completions past a capacity of 2 retaining nothing, a
response racing a queued control 64 times under -race, and an explicit refusal
for a return capability carrying no lifecycle. If that holds on a green run it
addresses the substance of observations 1–3, 6 and 7.

Two contract findings this repository owns

Recorded in #26. Neither is
settled by the upstream implementation choosing an answer.

1. The return capability's path space. The form reserves that capability's
non-empty paths for the invocation. Bitwire's access contract states only that
the capability supports its response — it neither grants nor refuses an
addressable path space there. Whether a return capability has one, and whether a
profile may reserve it, is shared meaning and belongs in the contract, not in one
profile's documentation. This needs an answer here before this issue closes.

2. The request-serial rule tightens nightseam.duplex/1 in place. The rule
itself is the profile's to make: the
ownership table
already assigns identifier minting and correlation to the profile, and the rule
is a real answer to the "newly arriving after reuse" race that ADR0003 says a
private generation counter cannot solve. But ADR0003 and this issue both require
an explicit compatibility or profile-version decision for changed wire semantics,
and tightening in place without naming a new version is exactly the case that
requires one. Accepting it needs its own stated reasoning. Bitwire's pinned
profile references are not repinned, and do not describe the tightened rule as
retained profile obligation, until that is recorded.

Remaining before this issue can close

• PR444 green. Its current run has failed and been re-triggered; the claimed
  evidence is not yet demonstrated by a passing gate.
• Observations 4 and 5 — early caller settlement against retained execution
  budget, and identity-deferred delivery, sibling/nested views, mounts and
  two-connection forwarding — rest on the generated/physical/tunnel/live
  acceptance in stage (e) rather than on the lifecycle packet itself. Link those
  runs separately from the composition evidence.
• Observation 8 is Bitwire's own: the contract and migration notes must name the
  profile integration requirement, and the handover must link actual Nightseam
  acceptance separately from this repository's test-only composition evidence.
  docs: record open contract review findings for the invocation lifecycle. #26 starts that; it completes when the two findings above are answered.
• A note on where signoff attaches: the 14:23Z decision on
  #439 splits the lane into an
  adoption PR closing #421 and a lifecycle PR closing #439, but PR444 currently
  carries all six stages and Closes #439 alone, and it is the only open PR on
  that lane. Whichever shape lands, this issue's evidence links should point at
  the commits that actually carry stage (c) and (d).

[jm9e]

PR444 is green; the remaining blockers are this repository's

Correcting the run status in my note above. When I wrote it, PR444 had a failed
fast (ubuntu-latest) and a cancelled Windows job, and I described its evidence
as claimed rather than demonstrated. That run has since completed: all six
checks — fast (ubuntu-latest), fast (windows-latest), protection, scope,
swift, full — are green. The PR is unmerged and still Closes #439.

The first item under "Remaining before this issue can close" is therefore
discharged. The stage (c) evidence — public lifecycle API, two independent
endpoint integrations, the opaque forwarding wrapper, both identity-reuse races,
latched cancellation, bounded captures and bodies, 32 sequential completions past
a capacity of 2, the 64-iteration -race response/control race, and explicit
refusal for a return capability carrying no lifecycle — now rests on a passing
gate rather than on the PR's assertion.

This remains a review of that account plus its gate. It is not a reading of the
implementation, and it is not signoff.

What is left, by owner

Bitwire's, and blocking this issue:

1. The return capability's path space — answer it in the access contract.
2. The compatibility disposition for tightening nightseam.duplex/1 in place.
3. Observation 8: the contract and migration notes naming the profile
   integration requirement, with Nightseam's acceptance linked separately from
   this repository's test-only composition evidence.

Both findings are now recorded on main in
integration.md,
with the contract and profile pages pointing at them
(#26, merged). Recording them is
not answering them.

To confirm against the merged commits, once they land:

• Observations 4 and 5 rest on the stage (e) generated/physical/tunnel/live
  acceptance rather than on the lifecycle packet. Link those runs separately from
  the composition evidence.
• Whichever shape the lane lands in, point this issue's evidence links at the
  commits that actually carry stages (c) and (d), per the note above.

[jm9e]

Nightseam's runtime evidence, from the 0.2.0 adoption lane

Nightseam #439 landed the adoption in ce70365a41409e54329c3883c2a888c965c1313b, and with it the observations this issue asks for. Summary of what was built and what it proves; the code is in Nightseam's runtime/go/ and runtime/ts/src/.

The representation. No new primitive, and no second native interface. An admitted request's return capability is the invocation, presented as a Wire: the empty path carries its outcome, as it always has, and invocation.capture, .ready, .release, .begin, .done and .control carry its lifecycle as ordinary events of the profile. Send returns on admission or refusal, so a refusal — retired, a bound reached, a capability that carries no lifecycle — is the error it returns; the participant mints the capture or body identifier, so no operation needs a return value. A participant needs Wire.Send and six path names: no import, no concrete type recognized, no endpoint unwrapped. ReturnAddress holding send-only Wire is what makes this possible, so v0.2.0's published declarations need no change and the tag stands.

Against the acceptance list:

• Asynchronous response, captured cancellation across detach/rebind, unchanged return identity — held in both languages, including a void/early-returning receiver whose body finishes later. The control reaches the receiver the request was delivered to; the rebound registration never sees it.
• More sequential completions than capacity, bounded unfinished work — 32 sequential completions past a capacity of 2 retire 32 times and retain nothing. Retirement is structural, not a timeout: each invocation is the state of one return capability, and it is released when the outcome is fixed, no capture is undelivered, no body unfinished and no control still reaching one.
• Response racing a queued control; same-key reuse — 64 raced completions under -race, retiring exactly once each. Race 1 (already-queued control) holds because the control is held by the invocation object, not by a key: a later invocation reusing the same textual identifier is a different object and the stale control reaches nothing. Race 2 (a newly arriving stale control) is closed at the carrier boundary by a profile rule ruled on #439 and landed in both tier-1 runtimes: request serials increase in publication order within one connection instance and one direction, gaps allowed, only request admission advancing the receiver's mark, a non-increasing serial ending the connection as a malformed frame does, reservation and publication under the outgoing queue's one ordering gate, a sender that would wrap refusing first, and every carrier bridge minting its own. A later invocation therefore has a greater serial, so an old control can never name it — with no used-id set and no tombstone. Recorded as a decision page and in the profile; the six tier-4 ports each hold an issue to conform and stay provisional until they do.
• Receiver timeout settles the caller early; the body keeps its budget — the execution lease is held until the body actually reports completion, so an early answer never retires an invocation whose body is still running.
• Identity-deferred delivery, sibling and nested views, mounts, two-connection forwarding — all exercised; forwarding over a pure route preserves the original return capability and the lifecycle that travels with it.
• Two independent same-profile integrations and an opaque forwarding wrapper, public facility only, no shared private ledger — one composes Nightseam's public Invocation; the other implements the vocabulary itself, with its own ledger, bounds, latch and retirement, composing none of Nightseam's lifecycle. Nightseam's dispatcher, its selected views and its generated-binder registration work identically against both, through an opaque wrapper that recognizes neither side. Execution owners report authoritative body completion through the public contract. Unsupported participation is explicit: a request whose return capability carries no lifecycle is refused on that capability rather than routed with weaker guarantees.
• Nested and repeated traversal, latching, bounded cost — each traversal takes a capture of its own, so a dispatcher visited twice in one invocation has two captures rather than one slot; cancellation latched while a capture is being installed reaches that capture when its delivery completes; captures and leases are bounded per invocation as totals, so neither depth nor shallow fan-out grows what one invocation retains.

The one thing the protocol form does not express, named rather than hidden: unforgeable attenuation between the verbs. One capability carries all of them, so the separation is by what a participant was handed rather than by what it can be cast to. A native-interface form does not establish it either — both its facades resolve from the same message — and holding a return capability is already full authority over its invocation, since it can settle it outright. Two smaller properties: a non-participant is detected by refusal, which is the ordinary obligation of every addressed receiver in this profile, not by type; and the refusal code a dispatcher reports is only as precise as the facility's error.

Nightseam's own disposition of this concern is recorded in an invocation is a Wire, and routing is composed above it. Closing or keeping this issue open is Bitwire's call; from Nightseam's side the observations exist and are linked.