External technical engagement evidence — NVIDIA OpenShell execution-generation lifecycle discussion #161

Classification

EXTERNAL_TECHNICAL_ENGAGEMENT / IMPACT_EVIDENCE

This record preserves a technically substantive external interaction in the NVIDIA/OpenShell repository. It is not ExecSurface validation, adoption, endorsement, reproduction, or P8 execution evidence.

External source

NVIDIA/OpenShell issue:
NVIDIA/OpenShell#4009

AETHER X technical comments:

• feat(sandbox): support stop requests conditional on sandbox execution identity NVIDIA/OpenShell#4009 (comment)
• feat(sandbox): support stop requests conditional on sandbox execution identity NVIDIA/OpenShell#4009 (comment)

External live SDK reproduction published by the issue author:

• feat(sandbox): support stop requests conditional on sandbox execution identity NVIDIA/OpenShell#4009 (comment)
• https://github.com/danehans/openshell-4009-repro

Technical contribution

The discussion isolates an execution-lifecycle boundary:

target identity != target generation

A stable sandbox identity/name is not sufficient to prove that a lifecycle action still targets the execution that produced an earlier observation.

The AETHER X comments proposed treating the action as a serialized compare-and-act operation over an execution incarnation/generation, while keeping two different replay dimensions separate:

• request_id — idempotency/admission identity for the operation;
• expected_execution — the execution generation the operation is permitted to affect.

The follow-up refined the contract further:

request_id -> {expected_execution, terminal_result}

so a retry after a successful conditional stop cannot be re-evaluated against a later replacement execution.

After the initial comment, the external issue author published a live Go SDK reproduction against an unpatched OpenShell Gateway. The reproduction demonstrated both relevant replacement classes:

• stop/start: sandbox ID remained stable while Status.MainProcessStartedAtMs changed; a delayed unconditional stop stopped the replacement;
• delete/recreate: sandbox ID changed; a delayed unconditional stop again stopped the replacement.

The external author explicitly characterized this as evidence of a missing API capability rather than a defect in unconditional Stop, and stated the repro could be extended to exercise a conditional-stop API once the design settles.

The AETHER X follow-up proposed an opaque execution-incarnation token issued by Gateway/supervisor authority, serialized precondition checking, fail-closed stale/unverifiable handling, and a concrete conformance matrix covering successful, stale, racing, retry and request-conflict cases.

Evidence boundary

What this does establish:

• substantive external technical engagement with a runtime lifecycle/evidence problem;
• an independently published live reproduction of the same stale-target class discussed in the AETHER X comment;
• evidence that execution-generation identity and idempotent lifecycle semantics are materially relevant to a real OpenShell API design problem;
• a concrete external scenario where observation identity and later lifecycle authority must remain causally bound.

What this does not establish:

• that NVIDIA or OpenShell adopted ExecSurface;
• that the external reproduction was derived solely from AETHER X comments;
• that NVIDIA endorses AETHER X or ExecSurface;
• that ExecSurface itself was executed in the reproduction;
• P8-A1 zero-assistance reproduction of ExecSurface;
• P8-A4 external real-workload use of ExecSurface;
• P9.5 production evidence.

Qualification

TECHNICALLY_USEFUL_NONINDEPENDENT_TO_EXECSURFACE_VALIDATION

Reason: the external thread and live reproduction support the relevance of an execution-generation / observation-to-effect binding concept. They do not validate the ExecSurface product.

Recommended retained wording

AETHER X contributed execution-generation and idempotency invariants to an NVIDIA/OpenShell conditional-stop design discussion. The issue author subsequently published a live SDK reproduction showing that delayed name-addressed stops can affect replacement executions across both stop/start and delete/recreate. This is retained as external technical engagement/impact evidence, not NVIDIA adoption, endorsement, or ExecSurface validation.

Product-boundary implication

No new ExecSurface product feature is authorized by this record.

If future OpenShell work exposes an authenticated execution-incarnation token or equivalent lifecycle precondition, any ExecSurface interoperability experiment must be opened under the existing evidence/interoperability governance and must preserve:

behavioral verdict != evidence completeness != observer authority

and

observed execution -> authenticated execution generation -> serialized lifecycle precondition -> effect

without claiming that runtime observation alone grants lifecycle authority.

Related internal tracking:

• external engagement / OpenSSF context: OpenSSF / Linux Foundation — Technical Community Engagement #94
• external distribution/engagement discipline: Distribution Sprint — external GitHub discovery & interoperability outreach (Alpha.5) #125
• P8 external-validation boundary: P8 — External Validation, Independent Reproduction & Architecture Criticism #114
• P9.5 real-workload boundary: Post-v1 — External real-workload evidence (historical P9.5) #140
• prior external technical engagement record: External technical engagement evidence — OpenAI Codex daemon continuity discussion #160